Talk:PubMan Func Spec Export/OAI Data Provider

Discussion

if the oai-pmh interface is to be provided as core service, how can it be solution specific - e.g. know what "Faces:Young" may mean? i'd find it natural, if sets are simply specified via escidoc id - escidoc:1234 - which is interpreted appropriately, i.e. if id identifies a container, list it's item, if it is an org unit, list affiliated items, if it is a context, list it's containers?--Robert 17:29, 16 December 2008 (UTC)

via oai-pmh users may define any sets they would like to. Therefore, Faces:Young was only an example. Some repositories offer even subject-specific sets, see more at OAI-PMH spec pages. --Natasa 09:18, 17 December 2008 (UTC)

i think this may be more flexibility than may be useful. i'd say the typical local admin doesn't really want to define any oai-pmh sets - they'd rather want oai-pmh to just work.--Robert 09:33, 17 December 2008 (UTC)

while i'm not quite sure whether oai-pmh should be part of search&export, one should definitely look at implementing oai-pmh under the general aspect of syndication, see also http://dev.livingreviews.org/presentations/mpdl_seminar_oaipmh.html .--Robert 17:46, 16 December 2008 (UTC)

that's nice idea we should check. --Natasa 09:23, 17 December 2008 (UTC)

• --Natasa 10:04, 17 December 2008 (UTC)I am still not certain that the data acquisition service is a good place for implementing the OAI_PMH data provider interface, and there are several reasons for it, and also some ideas placed below:
  • data acquisition service (DAAS) deals only with interfaces of other services i.e. it has no search and does not work with escidoc data storage directly
  • therefore, when we say DAAS shall talk oai-pmh i think it shall support it as source from eSciDoc (with oai_dc metadata).
  • one would still like to have it simply used without any further data definition (such as set definitions)
• OAI-PMH data provider interface shall be probably placed as one interface in search and export service
  • that would be in sync with feed definitions and the decision (see PubMan_Web_Syndication_Feeds#Outcome_of_the_SyndicationManager_design_and_architecture_meeting)that the syndication manager will become part of the search and export service
• search and export service would allow not only for definition of feeds (these already contain the search criteria in fact), but also for definition of various oai-pmh sets. In fact, probably we could use the same (i.e. current feed) definitions for both.
• if needed, in addition search and export service can also be extended to work with filters (i think the only reason for it would be if we would like to offer "withdrawn" items with status "deleted" via oai-pmh.

• Does it make sense to export all eSciDoc items?

according OAI-PMH specification, yes

• Does it make sense to export all items of a solution?

yes

• Do we provide only released item metadata over oai interface?

released and withdrawn items. Withdrawn items should be with status "deleted" in the header response. --Natasa 09:13, 16 December 2008 (UTC)

• OAI-Data provider interface is implemented for the eSciDoc repository
• OAI-Data provider shall allow defining sets and providing set description
  • Who will be allowed to define sets? --Kleinfercher 10:49, 16 December 2008 (UTC)
    • Repository managers e.g. local administrator of institute, in case of FACES, Faces admin etc. - in fact we should probably define a separate role, so that could be independently granted to users.

• Usage of ListRecords/List Identifiers verb of OAI-PMH interface could be invoked for a particular set, or without set parameter
  • if invoked without set parameter it shall provide information on sets in which this record/identifier is "grouped"
• find additional comments on the discussion page.--Robert 17:57, 16 December 2008 (UTC)

Questions

• I think as a next step we should think about implementing OAI-ORE, which also allows to "give away" the full text.

Coordinated Universal Time

Open Archives Initiative Protocol for Metadata Harvesting

Open Archives Initiative

Data As A Service

Enhanced Scientific Documentation