Talk:PubMan Func Spec Export/OAI Data Provider
Jump to navigation
Jump to search
Discussion[edit]
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.
Questions[edit]
- I think as a next step we should think about implementing OAI-ORE, which also allows to "give away" the full text.