On 6/24/15 12:20 PM, Godby,Jean wrote:
> Hi Karen,
> Good points. We are also troubled by the inheritance implications of 
> a WEMI model realized in RDF. In the OCLC linked data model of works, 
> every description is modeled as a schema:CreativeWork and is capable 
> of standing alone.

Jean, in a way you can also do this with BIBFRAME since none of the 
classes or properties are defined as disjoint each other. Tom Baker, 
Sean Petiya and I show this in an article we did on bibliographic models 
[1].  Most of us carry forward assumptions from pre-RDF data models, 
like object-oriented programming, and assume that the classes are 
restrictive - that is, that the definition of bf:workTitle with a domain 
of bf:Work means that bf:workTitle can only be used as a predicate for a 
pre-declared bf:Work. In fact, classes in RDF/OWL have a very different 
meaning [2], and it is the predicate that defines the subject as a work. 
(The blog post [2] explains that, I hope.)

With the BIBFRAME vocabulary, you can create a graph with a single 
identifier for the resource being described and use any properties from 
the vocabulary. The possibly negative consequence occurs when/if you 
apply inferencing to the triples -- the identified resource will be an 
instance of all of the classes of the properties that describe it. To 
translate: a single thing will be both a work and an instance because it 
will have properties with a domain of work and properties with a domain 
of instance. However, it is possible to also identify just the work 
properties or just the instance properties. These two views can 
co-exist. To me, the real impetus for embracing this in actual 
applications using BIBFRAME is for the simplicity of working with the 
data -- there will be times when a display is made up of properties 
taken from different BIBFRAME graphs, like a short display with author 
(Work), preferred title (Instance), and location (Item). Obviously at 
that point it's easier to have this graph:

short1 hasAuthor <author> .
short1 hasTitle <title> .
short1 hasLocation <location>.

rather than:

shortWork     hasAuthor <author> .
shortInstance hasWork shortWork .
shortInstance hasTitle <title> .
shortItem     hasInstance shortInstance .
shortItem     hasLocation <location> .

In fact, I believe that a SPARQL query can return the former but I 
haven't played with that.

We really should see the entities of BIBFRAME (as expressed by classes) 
as conveniences to be used when they make sense, but not as structures, 
since RDF data can be -- is designed to be -- viewed differently by 
different operations as needed. That's the flexibility of graphs.

At the moment, most of this discussion is focused on creating BIBFRAME 
data stores out of MARC data, and usually aggregating data from 
different sources. I think that skews our view. Data from a BIBFRAME 
data store can be displayed on the same page as data from, say, data in 
Dublin Core, where they both look more like my first example than my 
second. We haven't yet explored the possibilities that this flexibility 
gives us, although it sounds like OCLC is thinking in that direction. 
Keep it up, please!

[2] which I try to explain here:

> So an Item description could have titles, subjects, authors, and so 
> on, which might be factored out to Works, Expressions, and 
> Manifestations in a hierarchical model. We are still debating among 
> ourselves whether this result is theoretically interesting, or whether 
> it's a concession to the reality of working with aggregated data. But 
> I'm wondering where BF stands on this issue.
> Jean
> ------------------------------------------------------------------------
> *From:* Bibliographic Framework Transition Initiative Forum 
> <[log in to unmask]> on behalf of Karen Coyle <[log in to unmask]>
> *Sent:* Tuesday, June 23, 2015 6:01 PM
> *To:* [log in to unmask]
> *Subject:* Re: [BIBFRAME] The BIBFRAME Item Proposal: What we learned 
> by mapping it to
> On 6/22/15 2:24 PM, Godby,Jean wrote:
>> *Questions and minor issues*
>>   * ‚Äč How are the properties partitioned among 'Instance and 'Item'?
>>     The example described in the Proposal document implies that the
>>     'Item' class contains only properties indicating uniqueness --
>>     such as shelf location, bar code, etc -- while Instance would
>>     contain properties such as 'contributor,' 'creation date,' and
>>     'custodial history.' Is this correct? Or is there any bleeding
>>     between the Instance/Item line? For example, can an Item have an
>>     author or title, or is that information always maintained in the
>>     corresponding Instance description?
> Jean and Jeff,
> Great, and deep, analysis.
> As to the above, Iactually see this as more than a minor issue (and I 
> suppose you meant it as a question). This concept of a kind of "daisy 
> chain" of bibliographic levels was introduced in FRBR, but FRBR was 
> conceptually modeling a database design, not RDF. Folks often talk 
> about "inheritance" between, say, works and instances and items, but 
> in fact there is no inheritance in RDF. (There is in object-oriented 
> programming, which may be why people assume that it exists here.) 
> Given that RDF is kind of like disconnected bits of DNA that you hope 
> will all be there where you go looking for them, I see a danger in 
> relying on a graph two or three "links" away for essential information.
> I don't see why there cannot be a direct relationship between items 
> and authors. It could be just another set of graph relationships to 
> the same resources, or a shared identifier for the item/instance/work 
> "package". For some materials, e.g. art works or museum pieces, the 
> item will be the main focus of information and the separation into 
> work/instance/item may not be worth the costs.
> kc
> -- 
> Karen Coyle
> [log in to unmask]
> m: +1-510-435-8234
> skype: kcoylenet/+1-510-984-3600

Karen Coyle
[log in to unmask]
m: +1-510-435-8234
skype: kcoylenet/+1-510-984-3600