Now I see .. > I observer, that oaiprovider 1.2.2 provides a different identifier > than fedora commons 3.5.
The oaiprovider ignores the identifiers in the metadata and it does not use the PID from Fedora Commons, but makes its identifier from the <itemID> in the RELS-EXT datastream. Fixing RELS-EXT fixes the problem. I than forced the oaiprovider to provide the new data and only the new data by manually sweeping caches and databases. Is there a rebuild-interface for this task? --Jörg Knappen > Here are two sample identifiers: > > From the oaiprovider > http://fedora.clarin-d.uni-saarland.de/oaiprovider/?verb=ListRecords&metadataPrefix=oai_dc > > <identifier>oai:clarind-uds:croco</identifier> > > From fedora commons' native oai interface: > > http://fedora.clarin-d.uni-saarland.de/fedora/oai?verb=ListRecords&metadataPrefix=oai_dc > > <identifier>oai:fedora.clarin-d.uni-saarland.de:clarind-uds:croco</identifier> > > The difference is that the sever url is plugged in the native > response, but missing from the oaiprovider response. Is there a > standard how the response SHOULD look like and how do I enforce > conformity? > > --Jörg Knappen ------------------------------------------------------------------------------ This SF email is sponsosred by: Try Windows Azure free for 90 days Click Here http://p.sf.net/sfu/sfd2d-msazure _______________________________________________ Fedora-commons-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/fedora-commons-users
