 |
 |
Karen Coyle has some examples on her page: http://kcoyle.net/bibframe/. Your option #2 appears to be similar to the output in her examples, although her examples do not include the Item level. You can also find conversion programs on the BibFrame website which will let you convert MARC records and see what they look like in BibFrame RDF/XML. Steve McDonald [log in to unmask] -----Original Message----- From: Code for Libraries [mailto:[log in to unmask]] On Behalf Of Josh Welker Sent: Thursday, January 18, 2018 12:08 PM To: [log in to unmask] Subject: Re: [CODE4LIB] BIBFRAME nesting question I guess I am trying to figure out what the well-defined view looks like. I can't find examples that contain Work, Instance, and Item within the same RDF document at the same URI. In fact, the examples section on the LC BIBFRAME 2.0 website is blank, and the links for BIBFRAME 1.0 are all dead. I certainly am not trying to reinvent anything, which is why I am posting here. Joshua Welker Information Technology Librarian James C. Kirkpatrick Library University of Central Missouri Warrensburg, MO 64093 JCKL 2260 660.543.8022 On Thu, Jan 18, 2018 at 11:00 AM, McDonald, Stephen < [log in to unmask]> wrote: > BibFrame already has an RDF view which is well-defined. Are you > trying to come up with your own RDF model for BibFrame data? > > Steve McDonald > [log in to unmask] > > > -----Original Message----- > From: Code for Libraries [mailto:[log in to unmask]] On Behalf Of > Josh Welker > Sent: Thursday, January 18, 2018 11:28 AM > To: [log in to unmask] > Subject: [CODE4LIB] BIBFRAME nesting question > > Hi all, > > I have a question about how to model a resource expressed in BIBFRAME. > We are digitizing some unique collections. Ideally, I'd like to have > one URI like http://example.org/myuri that returns one RDF document > containing data about the Work, the Instance, and the Item. There are > two ways I could do > this: > > 1. Use Work as the parent type and include the Instance as a child > blank node using the Work.expressionOf property, and then include the > Item as a second-level child node using the Instance.hasItem property. Example: > > bf:Work: > bf:title: [title node here] > bf:hasInstance: > bf:Instance: > bf:bookFormat: [bookFormat node here] > bf:hasItem: > bf:Item: > bf:shelfMarker: [shelfMarker node here] > > > 2. Use some parent container class like rdf:Description and include > the Work, Instance, and item as immediate children blank nodes of that > container. Example: > > rdf:Description: > bf:Work: > bf:title: [title node here] > bf:Instance: > bf:bookFormat: [bookFormat node here] > bf:Item > bf:shelfMarker: [shelfMarker node here] > > > 3. If neither 1 nor 2 are acceptable, I could have separate URI > endpoints for the Work, Instance, and Item. This has the advantage of > using less blank nodes: > > http://example.org/myuri_Work > http://example.org/myuri_Instance > http://example.org/myuri_Item > > I really prefer option 3 the least, but I am very uncertain between 1 > and 2. Thoughts on which is best practice? If 2, what should I use as > the container class? And in any case, how much should I worry about > the proliferation of blank nodes? > > Joshua Welker > Information Technology Librarian > James C. Kirkpatrick Library > University of Central Missouri > Warrensburg, MO 64093 > JCKL 2260 > 660.543.8022 >