Print

Print


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.

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.

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

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]><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 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]<mailto:[log in to unmask]> http://kcoyle.net

m: +1-510-435-8234

skype: kcoylenet/+1-510-984-3600



--

Karen Coyle

[log in to unmask]<mailto:[log in to unmask]> http://kcoyle.net

m: +1-510-435-8234

skype: kcoylenet/+1-510-984-3600