On 6/25/15 8:28 AM, Trail, Nate wrote:
> I’m troubled by this idea that because rdf allows you to do something, 
> you have to do it that way.
> Shouldn’t each rdf resource be described by the properties in that 
> class, so you can re-use it?  In other words, it doesn’t make sense to 
> put Instance data on a Work, since then you’re not able to re-use that 
> Work for other Instances.
Two, no, three things: 1) The property has that domain regardless of 
where you use it, so if you want all of the work properties so that you 
can share them, you do so by extracting them (such as with a SPARQL 
query) and use them. 2) It isn't that you HAVE to do it that way, but 
you CAN do it that way, and someone WILL do it that way because a) 
there's no perfect data and b) people have different needs. 3) this is 
why using the domains of the properties is more accurate than relying on 
what subject people have used in triples that have an explicit rdf:type. 
Admittedly #3 requires inferencing, and most developers dislike it, but 
it's baked into the design of RDF.

> It is not the case that a bf:Work can have an extent of 300pp (on the 
> hardback) and 1webpage (on the electronic resource) of that Work. You 
> might express that, but you’d be wrong. Those properties describe the 
> manifestations, not the work.

What is this bf:Work? What defines it? All you have is an opaque 
identifier as a subject and predicates that describe the subject. The 
subject only is an instance of a class when a) it is explicitly typed as 
rdf:type bf:Work and/or b) you infer the class of the subject from the 
domains of the predicates. You don't "have" a bf:Work, you have a graph 
with predicates that describe a bf:Work.

(I think I make this clear in my blog post, but basically "things with 
creators are instances of bf:Work" not "bf:Works have creators". Also, 
there is a detailed description in the article I cited -- which, BTW, 
just won some prize that means that it will be available for open access 
for a year -- that's our prize money, essentially.)

> “for the simplicity of working with the data”
> If we go down this path, aren’t we describing a MARC record? “Tell me 
> everything I need to know about this thing in one place”.  You don’t 
> need to follow the link to the other resources, because I’ve ”cached” 
> everything locally right here.

Depending on how your vocabulary is defined and what inferences your 
applications make, with the same data you can have (at the same time) 
something with all of the properties of a MARC record as a single graph, 
separate graphs for bf:Work and bf:Instance, separate graphs 
representing frbrer:Work, frbrer:Expression, and frbrer:Manifestation. 
There isn't just one way to work with the same data -- it's not like 
having OO classes and records. The point of RDF is that the triples can 
form any number of different graphs, not unlike how a RDBMS allows you 
extract different views of the data (but with fewer restrictions).


> Nate
> -----------------------------------------
> Nate Trail
> Network Development & MARC Standards Office
> LA308, Mail Stop 4402
> Library of Congress
> Washington DC 20540
> *From:*Bibliographic Framework Transition Initiative Forum 
> [mailto:[log in to unmask]] *On Behalf Of *Karen Coyle
> *Sent:* Thursday, June 25, 2015 11:01 AM
> *To:* [log in to unmask]
> *Subject:* Re: [BIBFRAME] The BIBFRAME Item Proposal: What we learned 
> by mapping it to
> 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!
> kc
> [1]
> [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]> <mailto:[log in to unmask]> on 
> behalf of Karen Coyle <[log in to unmask]> <mailto:[log in to unmask]>
> *Sent:* Tuesday, June 23, 2015 6:01 PM
> *To:* [log in to unmask] <mailto:[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]  <mailto:[log in to unmask]>
> m: +1-510-435-8234
> skype: kcoylenet/+1-510-984-3600
> -- 
> Karen Coyle
> [log in to unmask]  <mailto:[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