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:
> 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] 
> <mailto:[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] <mailto:[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] <mailto:[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] <mailto:[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, 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]>  http://kcoyle.net
>>     m:+1-510-435-8234  <tel:%2B1-510-435-8234>
>>     skype: kcoylenet/+1-510-984-3600  <tel:%2B1-510-984-3600>
>>
>>     -- 
>>     Karen Coyle
>>     [log in to unmask]  <mailto:[log in to unmask]>  http://kcoyle.net
>>     m:+1-510-435-8234  <tel:%2B1-510-435-8234>
>>     skype: kcoylenet/+1-510-984-3600  <tel:%2B1-510-984-3600>
>
>     -- 
>     Karen Coyle
>     [log in to unmask]  <mailto:[log in to unmask]>  http://kcoyle.net
>     m:+1-510-435-8234  <tel:%2B1-510-435-8234>
>     skype: kcoylenet/+1-510-984-3600  <tel:%2B1-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