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