Thanks Richard, Jörg, I have it working now. There was an additional issue
with validation, which was logged in the database.
Julie
On 4 April 2012 15:10, Richard Green <[email protected]> wrote:
> 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
> **************************************************
>
--
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
