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
Steve.mcdonald_at_tufts.edu
-----Original Message-----
From: Code for Libraries [mailto:CODE4LIB_at_LISTS.CLIR.ORG] On Behalf Of Josh Welker
Sent: Thursday, January 18, 2018 11:28 AM
To: CODE4LIB_at_LISTS.CLIR.ORG
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
Received on Thu Jan 18 2018 - 12:00:31 EST