On 6/25/15 8:28 AM, Trail, Nate wrote:
[log in to unmask]" type="cite">

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.

[log in to unmask]" type="cite">

 

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.)

[log in to unmask]" type="cite">

 

“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).

kc

[log in to unmask]" type="cite">

 

Nate

 

-----------------------------------------

Nate Trail

Network Development & MARC Standards Office

LS/ABA/NDMSO

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 Schema.org

 

 

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] http://kcoyle.net/LHTv32n4preprint.pdf
[2] which I try to explain here: http://kcoyle.blogspot.com/2014/11/classes-in-rdf.html


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 Schema.org

 

 

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, I
  actually 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] 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

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