 |
 |
Thank you all for your input. It is helpful to know that there are no best practices per se but rather that it varies by use case. After starting this thread I also found some of the BF notes documents that also emphasize that there is no official position on things like blank nodes and that BF properties do not have explicit domains and ranges. I will take the analysis paralysis down a notch and perhaps elicit feedback after I actually have something complete. 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 2:17 PM, Stuart A. Yeates <[log in to unmask]> wrote: > > I > > haven't thought this through but because BF combines the FRBR work and > > expression into a single entity, it may be safe to say that no BF > > instance can be an instanceOf more than one BF work. > > Isn't every edition of 'Complete Works of Shakespeare' an instanceOf each > of the plays? > > cheers > stuart > -- > ...let us be heard from red core to black sky > > On 19 January 2018 at 08:49, Karen Coyle <[log in to unmask]> wrote: > > > Joshua, > > > > Yes, as Nate says, those examples on my site are from quite a while ago, > > and come out of an early MARC -> BFv1 converter. > > > > I don't how BF decides what gets a URI vs. what is a blank node (and I > > find it to be heavy on blank nodes, which may reflect an XML development > > environment). I do know that the FRBR model treats each bibliographic > > entity (WEMI) as a top-level "thing". FRBR also explicitly rejects the > > idea that the whole WEMI can be expressed with a single URI.[0] That > > seems extreme, but in fact in FRBR there are many-to-many relationships > > between works and expressions, so it isn't a hierarchy but a graph. I > > haven't thought this through but because BF combines the FRBR work and > > expression into a single entity, it may be safe to say that no BF > > instance can be an instanceOf more than one BF work. However, any BF > > work can have more than one instance, so the "super-set" identifier > > becomes difficult. > > > > My gut feeling is that you should analyze your own data based on your > > own use cases and then posit a model - so that your ideas are clear > > before you step into the morass of BF assumptions (many of which do not > > appear to be directly articulated in the public documentation). If you > > find that your use cases are not served by BF, PLEASE bring that to the > > attention of the community working on BF and LD4P [1]. There are aspects > > of the BF development that may meet the needs of some but not all, > > because the range of experiences is still limited. More voices are a > > Good Thing. > > > > kc > > [0] For more than you ever wanted to know, look at part II of > > http://kcoyle.net/beforeAndAfter/index.html > > [1] https://wiki.duraspace.org/display/LD4P > > > > On 1/18/18 11:26 AM, Josh Welker wrote: > > > Okay, thanks all. I will set up the code to split the entities into > > > different files. Is there a rule of thumb for when a Thing needs to be > > > split out into a different file with its own URI vs being a blank node? > > For > > > instance, maybe blank nodes one level deep are okay but nested ones are > > > not. But I don't see the point of making a URI for the Title of a > > yearbook, > > > for instance, when virtually no one is ever going to reference the > Title > > > outside the context of the larger Work or Instance. > > > > > > 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 12:39 PM, Trail, Nate <[log in to unmask]> wrote: > > > > > >> Just to note, that is a BIBFRAME1 vocab example. You can tell because > > the > > >> namespace is http://bibframe.org/vocab... > > >> > > >> You could certainly extract them and post them to their own end > points, > > >> but you have to decide how to make the uris unique in your endpoint > > area: > > >> Karen's had a unique uri for the Work: http://id/test/C:\Users\ > > >> deborah\Documents\OxygenXMLDeveloper\samples14107665 , but nothing > for > > >> the Instance. > > >> > > >> If she wanted, she could have posted the Work part to > > >> http://kcoyle.net/bibframe/works/samples1410665 > > >> And she could have posted the Instance part to > > http://kcoyle.net/bibframe/ > > >> instances/samples1410665 (and changed the bf:Instance bf:instanceOf > > >> address to the new work URI). > > >> > > >> <bf:instanceOf rdf:resource="http://kcoyle. > net/bibframe/works/ > > >> samples1410665 "/> > > >> > > >> > > >> > > >> BY the way, the bf2 version is comparable here (if I'm right that the > > >> number is the LC voyager bib id): > > >> > > >> Id.loc.gov/tools/bibframe/compare-id/full-rdf?find=14107665 or > > >> Id.loc.gov/tools/bibframe/compare-id/full-ttlf?find=14107665 > > >> It's also available for extraction and use here: > > >> http://lx2.loc.gov:210/LCDB?query=rec.id=14107665& > > recordSchema=bibframe2a& > > >> maximumRecords=1 > > >> > > >> Making things even more interesting, this one also has embedded Work > > >> descriptions : > > >> <bf:Work rdf:about="http://bibframe.example.org/14107665#Work740-46" > > > > >> <rdfs:label >Blest pair of sirens.</rdfs:label> > > >> > > >> They are pretty skimpy but could be used as stub descriptions and > given > > >> their own identity (uri) until such time as they can be reconciled to > an > > >> existing description or be more fully cataloged to stand on their own. > > >> > > >> Nate > > >> > > >> ----------------------------------------- > > >> Nate Trail > > >> Network Development & MARC Standards Office > > >> LS/ABA/NDMSO > > >> LA308, Mail Stop 4402 > > >> Library of Congress > > >> Washington DC 20540 > > >> > > >> > > >> > > >> > > >> -----Original Message----- > > >> From: Code for Libraries [mailto:[log in to unmask]] On Behalf > Of > > >> Josh Welker > > >> Sent: Thursday, January 18, 2018 1:03 PM > > >> To: [log in to unmask] > > >> Subject: Re: [CODE4LIB] BIBFRAME nesting question > > >> > > >> Stephen, > > >> > > >> I've looked at Karen Coyle's examples in the past. They are extremely > > >> helpful for figuring out how to structure the BIBFRAME record, but my > > >> question is more about how the BIBFRAME model interfaces with the > > semantic > > >> web as a whole. As you mentioned, Karen's examples, like the LC > examples > > >> Nate mentioned, have both Work and Instance objects at the top level. > > To my > > >> (limited) understanding, that makes them suitable for ingestion into a > > >> local system for indexing but not necessarily as URI endpoints. For > > >> example, if I were to reference http://kcoyle.net/bibframe/sr.rdf.xml > > in > > >> another RDF document, how would an application know if I am > referencing > > the > > >> Work or the Instance? > > >> > > >> 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:55 AM, McDonald, Stephen < > > >> [log in to unmask]> wrote: > > >> > > >>> 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 > > >>>> > > >>> > > >> > > > > -- > > Karen Coyle > > [log in to unmask] http://kcoyle.net > > m: +1-510-435-8234 > > skype: kcoylenet/+1-510-984-3600 > > >