Print

Print


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] <[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] <[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] <[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]> <[log in to unmask]> on behalf of
> Karen Coyle <[log in to unmask]> <[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 [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