Jörg
I don't think there is any requirement that your item [2] be the server name,
it is just a string to guarantee a unique ID overall. At Hull we just use our
basic domain name which protects against server migrations, for instance:
<oai:itemID
xmlns:oai="http://www.openarchives.org/OAI/2.0/";>oai:hull.ac.uk:hull:756</oai:itemID>
Richard
___________________________________________________________________
Richard Green
Consultant to Library & Learning Innovation, University of Hull
managing the History DMP and Hydra (Hull) Projects
http://hydra.hull.ac.uk
http://hydrangeainhull.wordpress.com
http://projecthydra.org
http://historydmp.wordpress.com
-----Original Message-----
From: Jörg Knappen [mailto:[email protected]]
Sent: 04 April 2012 2:30 PM
To: Julie Allinson
Cc: Support and info exchange list for Fedora users.
Subject: Re: [fcrepo-user] oaiprovider problem: identifier different from
fedora commons native identifier
Hi Julie,
> Hi Jörg,
>
> I'm having exactly this problem. Are you saying that you have replaced
>
> <oai:itemID>oai:FEDORA_PID</oai:itemID>
>
> with
>
> <oai:itemID>FEDORA_PID</oai:itemID> (which for us would be something
> like york:1000)
>
> and it just worked? I've done this, and have dropped all of the
> database tables and redeployed the app, but it's still saying 'no records
> found'.
Here is what my RELS-EXT datastream finally looks like (in the fedora/admin
interface; it may look differently when viewed with another method!)
<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#";>
<rdf:Description rdf:about="info:fedora/clarind-uds:genie">
<itemID
xmlns="http://www.openarchives.org/OAI/2.0/";>oai:fedora.clarin-d.uni-saarland.de:clarind-uds:genie</itemID>
</rdf:Description>
</rdf:RDF>
The itemID is 4-part:
1. The fixed string oai
2. The location of our server
3. The prefix specific to our repository 4. The given PID to this item
fedora/oai uses 3+4 from its own database and adds 1+2 automatically.
Fedora native can do without any RELS-EXT datastream.
oaiprovider uses the RELS-EXT datastream and needs the fully specified itemID.
I wonder how good it is to include the server location, because the server
location may change over time. On the other hand, it guarantees uniqueness of
the identifier because there is no registry known to me for part 3 (the prefix).
> Any pointers greatly appreciated!
Hope this helps.
--Jörg
> Julie
>
>
>
>
>
>
>
> On 21 March 2012 09:19, Jörg Knappen <[email protected]> wrote:
>
>> I observer, that oaiprovider 1.2.2 provides a different identifier
>> than fedora commons 3.5.
>>
>> 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&me
>> tadataPrefix=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
>>
>
>
>
> --
> Julie Allinson <[email protected]> Digital Library Manager
> University Library & Archives, Harry Fairhurst Building University of
> York, Heslington, York, YO10 5DD, UK
> tel: ++44 (0) 1904 324083
> skype: j.allinson gtalk: [email protected]
> twitter: julieallinson
> web: http://dlib.york.ac.uk/
> blog: http://yorkdl.wordpress.com/
>
> calendar: http://tinyurl.com/jal-gcal
> disclaimer: http://www.york.ac.uk/docs/disclaimer/email.htm
>
------------------------------------------------------------------------------
Better than sec? Nothing is better than sec when it comes to monitoring Big
Data applications. Try Boundary one-second resolution app monitoring today.
Free.
http://p.sf.net/sfu/Boundary-dev2dev
_______________________________________________
Fedora-commons-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/fedora-commons-users**************************************************
To view the terms under which this email is
distributed, please go to
http://www2.hull.ac.uk/legal/disclaimer.aspx
**************************************************
------------------------------------------------------------------------------
Better than sec? Nothing is better than sec when it comes to
monitoring Big Data applications. Try Boundary one-second
resolution app monitoring today. Free.
http://p.sf.net/sfu/Boundary-dev2dev
_______________________________________________
Fedora-commons-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/fedora-commons-users
