 |
 |
Stuart, I think it goes the other way - every instance of the complete works (aka a new publication of that) is also an instance of some expression of the work of each play. Note that such compilations do not have a good solution (yet?) in the FRBR/FRBR-LRM world. The solution that the original FRBR group came up with [1] was that every manifestation with multiple works/expressions is both: - an expression of a work in its own right. Thus, the Complete works is itself an expression and a work - multiple links to individual expressions/works My theory on this is that the underlying problem is that manifestations are NOT expressions of a work, but are packages that can have an expression or more, plus other things, like introductions, indexes, etc. It doesn't make sense to me to consider that there is a progression from expression to manifestation without adding in the package aspect, which is what publishing adds. But this gets really head-bangingly hard pretty quickly. Just to say that we should not assume that FRBR actually works with real data - it was never tested as such. kc [1] https://www.ifla.org/files/assets/cataloguing/frbrrg/AggregatesFinalReport.pdf On 1/18/18 12:17 PM, Stuart A. Yeates 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 >> -- Karen Coyle [log in to unmask] http://kcoyle.net m: +1-510-435-8234 skype: kcoylenet/+1-510-984-3600