Print

Print


Stephen, I didn't entirely follow what you said here so maybe some examples would help. In spite of the studies done by the FRBR Working Group on Aggregates [1], I'm not entirely convinced that whole/part problem is solved. The part/whole relationships are complicated by the fact that each of the Group 1 entities can have part/whole relationships. It boggles my mind to think of how complex that gets when you have an expression that is part of another expression and is expressed in a part of a manifestation... At least BIBFRAME has one less entity. Heidrun Wiesenmüller did some diagrams [2] that are just the tip of the iceberg and yet make one shudder. I suspect that FRBRoo [3] has thought this through better than most models. BIBFRAME has "hasPart" and "partOf" but I don't know how these are being implemented.

kc
[1] http://www.ifla.org/node/923
[2] https://www.mendeley.com/profiles/heidrun-wiesenmuller/
[3] http://cidoc-crm.org/frbr_inro.html, and especially http://cidoc-crm.org/frbr_graphical_representation/graphical_representation/work_expression_static.html which shows a "container work"

On 6/25/15 4:15 PM, Stephen Hearn wrote:
[log in to unmask]" type="cite">
There seems to be an assumption here and in the article Karen cites that multiplicity only matters in terms of a resources multiple levels, but there are lots of resources which contain more than one work, more than one expression, etc. Inferring a domain class from a property relationship depends on being able to identify which of the entities in that class in a resource is being described. That would seem to entail either some referencable enumeration of the works, expressions, etc. a resource contains, or a separation of the descriptive statements into graphs for each work, expression, etc. If that's the case, then relying on domain classes implied by property relationships doesn't save us from having to sort out entities and by implication entity types as we build descriptions.

Stephen

On Thu, Jun 25, 2015 at 4:14 PM, Karen Coyle <[log in to unmask]> wrote:
Ray, although I don't recall this particular proposal, the BIBFRAME A-V study[1] did make similar recommendations based on their needs. They propose a super-class, bf:Content, as a solution to their need to make use of some bf:Instance properties at a higher level than instance:

"There are several properties already available in BIBFRAME that support the needs of moving image and recorded sound works or events, but these are restricted to the Instance domain. These include bf:duration, bf:soundContent, bf:colorContent, and bf:aspectRatio. By allowing these properties to be used with bf:Content, catalogers can describe the original intention/characteristics of the content, even if that is quite different from the characteristics of an instance in the collection." (p. 42 of that report, on the BIBFRAME web site)

Other such requests can be intuited from some of the literature from non-book catalogers regarding FRBR, where their needs do not divide up the bibliographic universe in the same way that FRBR WEMI does.

kc
[1] http://www.loc.gov/bibframe/pdf/bibframe-avmodelingstudy-may15-2014.pdf


On 6/25/15 10:22 AM, Denenberg, Ray wrote:

The issue of carrying Instance information in Items is completely analogous to carrying Work information in Instances, right?  Item is a recently introduced concept, but Works and Instances are as old as BIBFRAME.  I don’t recall anyone ever raising this issue; why has it never been brought up in the several years since the BIBRAME model was introduced?

 

Ray

 

From: Bibliographic Framework Transition Initiative Forum [mailto:[log in to unmask]] On Behalf Of Young,Jeff (OR)
Sent: Thursday, June 25, 2015 12:47 PM
To: [log in to unmask]
Subject: Re: [BIBFRAME] The BIBFRAME Item Proposal: What we learned by mapping it to Schema.org

 

I think the question is more about applying work properties to instance entities (or even Items) rather than suggesting it’s a good idea in the other direction.

 

Jeff

 

From: Bibliographic Framework Transition Initiative Forum [mailto:[log in to unmask]] On Behalf Of Trail, Nate
Sent: Thursday, June 25, 2015 11:28 AM
To: [log in to unmask]
Subject: Re: [BIBFRAME] The BIBFRAME Item Proposal: What we learned by mapping it to Schema.org

 

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]> 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



--
Stephen Hearn, Metadata Strategist
Data Management & Access, University Libraries
University of Minnesota
160 Wilson Library
309 19th Avenue South
Minneapolis, MN 55455
Ph: 612-625-2328
Fx: 612-625-3428
ORCID:  0000-0002-3590-1242

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