Talk:OAI-ORE Publication Item

Example: Aggregation of a eSciDoc publication item

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

Aggregation

Could a ReM part look as follows?

       Components
       <ore:aggregates rdf:resource="http://coreservice.mpdl.mpg.de:8080/ir/item/escidoc:66202/components/component/escidoc:68328"/>
       <ore:aggregates rdf:resource="http://coreservice.mpdl.mpg.de:8080/ir/item/escidoc:66202/components/component/escidoc:68329"/>
       Metadata formats
       <ore:aggregates rdf:resource="http://pubman.mpdl.mpg.de:8080/dataacquisition/view/unapi?id=escidoc:66202&format=bibtex"/>
       <ore:aggregates rdf:resource="http://pubman.mpdl.mpg.de:8080/dataacquisition/view/unapi?id=escidoc:66202&format=endnote"/>
       <ore:aggregates rdf:resource="http://pubman.mpdl.mpg.de:8080/dataacquisition/view/unapi?id=escidoc:66202&format=escidoc"/>
       <ore:aggregates rdf:resource="http://pubman.mpdl.mpg.de:8080/dataacquisition/view/unapi?id=escidoc:66202&format=APA_text/html"/>
       <ore:aggregates rdf:resource="http://pubman.mpdl.mpg.de:8080/dataacquisition/view/unapi?id=escidoc:66202&format=APA_application/pdf"/>
       <ore:aggregates rdf:resource="http://pubman.mpdl.mpg.de:8080/dataacquisition/view/unapi?id=escidoc:66202&format=APA(Snippet)_application/xml"/>
       <ore:aggregates rdf:resource="http://pubman.mpdl.mpg.de:8080/dataacquisition/view/unapi?id=escidoc:66202&format=AJP_text/html"/>
       <ore:aggregates rdf:resource="http://pubman.mpdl.mpg.de:8080/dataacquisition/view/unapi?id=escidoc:66202&format=AJP_application/pdf"/>
       <ore:aggregates rdf:resource="http://pubman.mpdl.mpg.de:8080/dataacquisition/view/unapi?id=escidoc:66202&format=AJP(Snippet)_application/xml"/>
       Relations
       <rdfs:seeAlso rdf:resource="http://pubman.mpdl.mpg.de/pubman/item/escidoc:66202:14"/>
       <ore:similarTo rdf:resource="http://dx.doi.org/10.1073/pnas.0903616106"/>
       <ore:isAggregatedBy rdf:resource="escidoc:133823"/>

Discussion

• 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 (http://hdl.handle.net/1234/567) 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? (http://handle.net/)--Robert 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: http://www.openarchives.org/ore/1.0/http#RedirectNoCN. 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 handle.net 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)

Questions

• how resources in eSciDoc should be exposed when we deal with ORE formats?
  • pubman.mpdl.mpg.de/item/escidoc:1234 (by default it goes to pubman presentation, content negotiation to be implemented in each solution web server)
  • resources.mpdl.mpg.de/hdl:1234345 or resources.mpdl.mpg.de/escidoc:1234 (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
  • resources.mpdl.mpg.de/hdl:1234345.rdf, resources.mpdl.mpg.de/hdl:1234345.atom, resources.mpdl.mpg.de/hdl:1234345.html (new presentation format? or would just point to pubman.mpdl.mpg.de/item/escidoc:12345 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 resources.mpdl.mpg.de/hdl:1234345.html 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 resources.mpdl.mpg.de/escidoc:1234 ?

• 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: pubman.mpdl.mpg.de/md/escidoc:1234 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

--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 levele 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

Publication Item	Graph	Comment
Creator.CreatorType.Person
Creator.CreatorType.Organization
Creator.CreatorType.Person
Creator.CreatorType.Organization
Title
Alternative Title
Language
Identifier.Id		TODO: Different types
PublishingInfo.Publisher
PublishingInfo.Place
PublishingInfo.Edition
Date		TODO: Different types
TotalNumberOfPages
Degree
Abstract
Subject
TableOfContents
Location
Genre
Event
Language
Review Method
Source
Source.Title
Source.Genre
Source.Alternativetitle
Source.Creator.CreatorType.Person
Source.Creator.CreatorType.Organization
Source.Volume
Source.Issue
Source.StartPage
Source.EndPage
Source.Identifier.Id
Source.TotalNumberOfPages
Source.Publisher
Source.PublishingInfo
Source.Place
Source.Edition

Example Data

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

arXiv example:
   <rdf:Description rdf:about="http://arxiv.org/rem/rdf/astro-ph/0601007"> 

       <ore:describes rdf:resource="http://arxiv.org/aggregation/astro-ph/0601007"/> 

       <dcterms:creator rdf:parseType="Resource"> 

           <foaf:name>arXiv.org e-Print Repository</foaf:name> 

           <foaf:page rdf:resource="http://arXiv.org" /> 

       </dcterms:creator> 

       <dcterms:created rdf:datatype="http://www.w3.org/2001/XMLSchema#dateTime">2008-10-01T18:30:02Z</dcterms:created> 

       <dcterms:modified rdf:datatype="http://www.w3.org/2001/XMLSchema#dateTime">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="http://creativecommons.org/licenses/by-nc/2.5/"/> 

   </rdf:Description>

Description of A

arXiv example:
 <rdf:Description rdf:about="http://arxiv.org/aggregation/astro-ph/0601007"> 

       <ore:isDescribedBy rdf:resource="http://arxiv.org/rem/atom/astro-ph/0601007"/>

       <ore:isDescribedBy rdf:resource="http://arxiv.org/rem/xhtml/astro-ph/0601007" />

       <dc:title>Parametrization of K-essence and Its Kinetic Term</dc:title>

       <dcterms:created rdf:datatype="http://www.w3.org/2001/XMLSchema#dateTime">2005-12-31T04:01:23Z</dcterms:created>

       <dcterms:modified rdf:datatype="http://www.w3.org/2001/XMLSchema#dateTime">2006-01-18T06:16:15Z</dcterms:modified>

       <dcterms:creator rdf:parseType="Resource">

           <foaf:name>Hui Li</foaf:name>

           <foaf:mbox rdf:resource="mailto:lihui@somewhere.cn" />

       </dcterms:creator>

       <dcterms:creator rdf:parseType="Resource">

           <foaf:name>Zong-Kuan Guo</foaf:name>

       </dcterms:creator>

       <dcterms:creator rdf:parseType="Resource">

           <foaf:name>Yuan-Zhong Zhang</foaf:name>

       </dcterms:creator>

       <ore:aggregates rdf:resource="http://arxiv.org/abs/astro-ph/0601007"/>

       <ore:aggregates rdf:resource="http://arxiv.org/pdf/astro-ph/0601007"/>

       <ore:aggregates rdf:resource="http://arxiv.org/ps/astro-ph/0601007"/>

       <ore:aggregates rdf:resource="http://arxiv.org/ps/astro-ph/0601007?dpi=600&font=bitmapped"/>

       <ore:aggregates rdf:resource="http://arxiv.org/ps/astro-ph/0601007?dpi=300&font=bitmapped"/>

       <ore:aggregates rdf:resource="http://arxiv.org/ps/astro-ph/0601007?fname=cm&font=TypeI"/>

       <ore:aggregates rdf:resource="http://arxiv.org/dvi/astro-ph/0601007"/>

       <ore:aggregates rdf:resource="http://export.arxiv.org/oai2?verb=GetRecord&metadataPrefix=oai_dc&identifier=astro-ph/0601007"/>

       <ore:aggregates rdf:resource="http://arxiv.org/cits/astro-ph/0601007"/>

       <ore:aggregates rdf:resource="http://www.citebase.org/abstract?id=oai:arXiv.org:astro-ph/0601007"/>

       <rdfs:seeAlso rdf:resource="http://arxiv.org/abs/astro-ph/0601007"/>

       <rdfs:seeAlso rdf:resource="http://jp.arxiv.org/aggregation/astro-ph/0601007"/>

       <ore:similarTo rdf:resource="info:arxiv/astro-ph/0601007"/>

       <ore:similarTo rdf:resource="info:doi/10.1142/S0217732306019475"/>

   </rdf:Description>

Enhanced Scientific Documentation

Display Data Channel

Coordinated Universal Time

Open Archives Initiative Object Reuse and Exchange

Uniform Resource Identifier

HyperText Transfer Protocol

Uniform Resource Locator

Open Archives Initiative Protocol for Metadata Harvesting

Reference Management Software for Lists of References