Talk:OAI-ORE Publication Item

From MPDLMediaWiki
Jump to navigation Jump to search

Example: Aggregation of a eSciDoc publication item[edit]

This aggregation is an example of the publication escidoc:66202.


PubItem Aggregation2.jpg

Could a ReM part look as follows?

       <ore:aggregates rdf:resource=""/>
       <ore:aggregates rdf:resource=""/>
       Metadata formats
       <ore:aggregates rdf:resource=""/>
       <ore:aggregates rdf:resource=""/>
       <ore:aggregates rdf:resource=""/>
       <ore:aggregates rdf:resource=""/>
       <ore:aggregates rdf:resource=""/>
       <ore:aggregates rdf:resource=""/>
       <ore:aggregates rdf:resource=""/>
       <ore:aggregates rdf:resource=""/>
       <ore:aggregates rdf:resource=""/>
       <rdfs:seeAlso rdf:resource=""/>
       <ore:similarTo rdf:resource=""/>
       <ore:isAggregatedBy rdf:resource="escidoc:133823"/>


  • Collection - Collection is a resource with its own Resource Map which aggregates Publications (each having own resource maps). The publication aggregation should express this relation by "aggregatedIn".
  • DDC Subject - Not part of the aggregation, only linked
  • Authors - linked via rdf:resource attributes of dc:creator, possibly with a nested link to the organizational units
  • Express eSciDoc publication item - use standard dcTerms/foaf

  • Are the escidoc metadata profiles part of the aggregation, or is this implicitly via escidoc.xml
Also a relation?, but anyway referenced in the escidoc.xml --Friederike 06:48, 29 June 2009 (UTC)
IMHO escidoc metadata profiles are directly aggregated and not via relations. --Natasa 11:13, 30 June 2009 (UTC)
  • In general, i think we should first determine which atomic resources we want to publish as simple linked data; once this is in place, it will be easier to experiment with different levels of granularity/completeness of resource maps. experimentation and flexibility in this regard will be needed anyway, because the use cases for resource maps are not entirely clear yet - or are they?--Robert 12:39, 26 June 2009 (UTC)
I think resource maps should help getting the resource in appropriate representation format. Would not these be e.g. citation style in a format, html, rdf, xml, etc...? Maybe we should try to map first to OAI-ORE data model more precisely? --Natasa 11:13, 30 June 2009 (UTC)
For me the primary use case is to 'explain' out data to the web in a proper way. I think that the oai-ore approach makes totally sense and fits into our idea of a publication very well.--Friederike 14:13, 2 July 2009 (UTC)
  • Item -> Aggregation (identified by Handle URI hdl:1234/567), the aggregation identifier is actually the handle-uri.
i don't think non-HTTP URIs make much sense for oai-ore.--Robert 17:12, 30 June 2009 (UTC)
I actually like the idea of using handles for identifying an aggregation as you always can resolve a handle ( and there you have an http URL :)
- These urls are stable
- They do not contain system specific stuff like faces, .jsp or so on and therefore are good for content negotiation, as well
--Friederike 08:22, 2 July 2009 (UTC)
how are you going to implement content negotiation capabilities for an HTTP server that's not under your control? ( 08:50, 2 July 2009 (UTC)
Good point. There are some recommendations from the oai-ore guys. Will check them.--Friederike 08:53, 2 July 2009 (UTC)
This is what we should do if we can not provide content negotiation: We should carefully consider pros and cons of using the handle as the aggregation identifier. (Perhaps a topic for the Architectural Board)? --Friederike 09:17, 2 July 2009 (UTC)
well, having return HTTP 303 won't work either. it's just not under our control. in general i think it is problematic to mint HTTP URLs which are not in our domain.--Robert 13:29, 2 July 2009 (UTC)


  • how resources in eSciDoc should be exposed when we deal with ORE formats?
    • (by default it goes to pubman presentation, content negotiation to be implemented in each solution web server)
    • or (by default runs on core-services server, content negotiation to be implemented only there)
I prefer this more generic url and it actually makes sense to have content negotaiation implemented only once. additionally it is more transparent as it might not be of interest which appplication provides/deals with a resource.--Friederike 08:36, 8 July 2009 (UTC)
i don't think this will work. we should actually wait and see what happens with the OAI-PMH implementation. my predicition is that also there we'll have to include some solution-specific logic.--Robert 08:52, 8 July 2009 (UTC)
I agree with Robert, additionally we can implement it by our self and the core service development does not need to be involved--Friederike 12:26, 10 July 2009 (UTC)
Ok, but my point was not to run together with the core services, but to offer this on same server :) which is a difference ... and as we are talking on resources, we can only talk on resource specific logic and not on solution specific logic --Natasa 12:42, 16 July 2009 (UTC)
    • resource maps would therefore respectively be
    •,, (new presentation format? or would just point to as this is only a web page not based on item resource map if we would like to be formal)
    • I would not introduce a new presentation format, the request for the generic url resolves in the solution presentation of this item.--Friederike 08:36, 8 July 2009 (UTC)
how does the core service know which solution's presentation URL to resolve to? Or does this mean that there's one distinguished or canonical solution associated with each item (via the content model?)?--Robert 08:52, 8 July 2009 (UTC)
i do not think that the core service will now it, my previous comment was actually reflecting to separate service, which will reside on same server with the core service... in addition, should not this be in the aggregation definition?"is describedBy" there can be more... maybe the use of a "splash" page as well comes as option? --Natasa 12:53, 16 July 2009 (UTC)
      • same as above, only use ?

  • remove transformations of the publication item from the resource maps as aggregates?
Would not do that. we should not mix metadata formats and item formats
For publication we will have item format rdf, atom, html
For metadata we will have format bibtex, endnote etc.

Therefore retrieving publication metadata is imo not part of content negotiation. Additionally I checked the example from arXiv, they as well aggregate oai_dc metadata in their ReM.--Friederike 08:36, 8 July 2009 (UTC)

Perhaps we could provide the md record of an item for content negotiation? Like: for bib, enl, xml (here we have various!?) etc.--Friederike 09:26, 8 July 2009 (UTC)
i'd stick to mime-types for content negotiation, i.e. whatever can reasonably be sent in an HTTP Accept header, which probably excludes BibTeX and probably also Endnote. In any case, implementing such things without clear use cases will at best be experimental and should be treated as such.--Robert 10:29, 8 July 2009 (UTC)
Would agree, metadata formats should not be mixed with the content negotiation issue. I also would thing that all these transformations are not aggregates, but, maybe they can be expressed as proxies? --Natasa 13:09, 16 July 2009 (UTC)

Concept Questions[edit]

--Friederike 11:40, 15 July 2009 (UTC)

  • Just to get a start here, we perhaps should agree on basic steps for oai-ore. (and yes we always should see this service as experimental, as we do not have clear use cases.)
  1. Design a own service "OAI-ORE Service"
  1. Can be used by various solutions
  2. Provides (talks to transformation service) Transformation from escidoc-publication-item to oai-ore rdf (only publication for start, later we can deal with other contents)
this step is the one i would not agree with. I would actually start the other way around. Have {item, container}->oai-ore level mapping and then specialize if needed. --Natasa 13:14, 16 July 2009 (UTC)
  1. Deals with content negotiation on mime-type level

If we can get this far I bet we all have a clearer image of functionalities such a service should provide.

Aggregation Metadata[edit]

Publication Item Graph Comment
Alternative Title
Identifier.Id TODO: Different types
Date TODO: Different types
Review Method

Example Data[edit]

The following examples have been copied from the ORE User Guide - Resource Map Implementation in RDF/XML. Please note that currently no OAI-ORE implementation seems to be available for arXiv, therefore all corresponding URLs can't be resolved.

Description of ReM[edit]

arXiv example:
   <rdf:Description rdf:about=""> 
<ore:describes rdf:resource=""/>
<dcterms:creator rdf:parseType="Resource">
<foaf:name> e-Print Repository</foaf:name>
<foaf:page rdf:resource="" />
<dcterms:created rdf:datatype="">2008-10-01T18:30:02Z</dcterms:created>
<dcterms:modified rdf:datatype="">2008-10-03T07:30:34Z</dcterms:modified>
<dc:rights>This Resource Map is available under the Creative Commons Attribution-Noncommercial 2.5 Generic license</dc:rights>
<dcterms:rights rdf:resource=""/>

Description of A[edit]

arXiv example:
 <rdf:Description rdf:about=""> 
<ore:isDescribedBy rdf:resource=""/>
<ore:isDescribedBy rdf:resource="" />
<dc:title>Parametrization of K-essence and Its Kinetic Term</dc:title>
<dcterms:created rdf:datatype="">2005-12-31T04:01:23Z</dcterms:created>
<dcterms:modified rdf:datatype="">2006-01-18T06:16:15Z</dcterms:modified>
<dcterms:creator rdf:parseType="Resource">
<foaf:name>Hui Li</foaf:name>
<foaf:mbox rdf:resource="" />
<dcterms:creator rdf:parseType="Resource">
<foaf:name>Zong-Kuan Guo</foaf:name>
<dcterms:creator rdf:parseType="Resource">
<foaf:name>Yuan-Zhong Zhang</foaf:name>
<ore:aggregates rdf:resource=""/>
<ore:aggregates rdf:resource=""/>
<ore:aggregates rdf:resource=""/>
<ore:aggregates rdf:resource=""/>
<ore:aggregates rdf:resource=""/>
<ore:aggregates rdf:resource=""/>
<ore:aggregates rdf:resource=""/>
<ore:aggregates rdf:resource=""/>
<ore:aggregates rdf:resource=""/>
<ore:aggregates rdf:resource=""/>
<rdfs:seeAlso rdf:resource=""/>
<rdfs:seeAlso rdf:resource=""/>
<ore:similarTo rdf:resource="info:arxiv/astro-ph/0601007"/>
<ore:similarTo rdf:resource="info:doi/10.1142/S0217732306019475"/>