Rob, it's not a theoretical question but a practical one. Much of the 
existing bibliographic data in the world does not follow FRBR or 
BIBFRAME, and many communities may never think about the difference 
between a Work and an Instance.

An easy example is a standard citation -- of which there are bazillions 
in the gazillions of already published articles, many of which are being 
digitized. A standard citation has elements like:

author (bf:Work)
title (bf:Instance)
publisher (bf:Instance)
date (bf:Instance)
pages (bf:Instance)

Should this data be coded in BibTex,, or whatever, it will 
almost certainly have a single resource identity to which the metadata 
elements are assigned. Presumably, at some point, this data and library 
data will be swimming in the same LoD soup, available for exploration 
and recombination.

(Note that a lot of work is going into making citations linkable, e.g. 
at PLOS.)

Then look at the folks who are intending to follow FRBR -- e.g. RDA -- 
and you see a different division that (arguably) has three abstract 
levels and one physical one. (You could argue that bf:Instance is still 
abstract, because it does not have actually physicality; that is 
reserved for the bf:Item.)

In addition, some communities within GLAM have argued that their 
division between abstract and physical will differ from what has been 
laid out in FRBR and BIBFRAME. The most radical case is that of the 
unique museum piece or work of art, which some art librarians consider 
indivisible, at best encompassing frbr:work and frbr:item, but 
apparently that isn't universally accepted. The A-V people have already 
weighed in to BIBFRAME that they need some bf:Instance properties 
available for bf:Work. [1]

Basically, there's not going to be a single interpretation of the 
entities of description. What we need, then, is to pursue the most 
efficient route to interoperability.


On 11/6/14 10:22 AM, Robert Sanderson wrote:
> Hi Karen, all,
> I'm confused as to when a resource can be both a Work and an Instance 
> at the same time.  When can a resource be both an abstract concept 
> (Work) and a class of physical objects (Instance)?
> I don't mind if people do inferencing in the privacy of their 
> consuming application, but I definitely don't want to require it for 
> every application -- be as simple as possible and no simpler.  The 
> simple method here, IMO, is to be explicit about the class of the 
> resource.
> Rob
> On Wed, Nov 5, 2014 at 11:56 AM, Karen Coyle <[log in to unmask] 
> <mailto:[log in to unmask]>> wrote:
>     On 11/4/14 5:01 PM, Robert Sanderson wrote:
>     >>
>     Surely the subject's class is determined by a statement with the
>     predicate "rdf:type"?
>     >
>     You can *infer* a class based on the range or domain of
>     predicates, but that doesn't somehow trump an absolute assertion
>     ... which all of the examples have, and should be mandatory in any
>     reasonable implementation.
>     It's actually easier to *not* do it this way, as you can generate
>     unintended inferences.  If you mistakenly attached instanceTitle
>     to a Work, that's not an error, it just implies to a reasoner that
>     the Work is also an Instance. Much easier to just consistently use
>     bf:title that has no such inferences.
>     >>
>     [snip much]
>          If BIBFRAME is not assuming that the work title and the
>         instance title are key "definers" of the entity, then that is
>         fine. 
>     >
>     >BibFrame should not do this if it is, and therefore it is (or should be) fine. :)
>     Well, this is where we disagree. But perhaps we just have
>     different use cases. It sounds like you are warning BIBFRAME not
>     to do inferencing, but in the open world, inferencing cannot be
>     prevented. If you want to prevent inferencing on Works and
>     Instances then you need to eliminate those as classes for all
>     properties. If you want to prevent any combination of Work and
>     Instance graphs, then you have to get into some strict
>     disjointness, but which only applies when inferencing occurs.
>     Pretty ugly stuff.
>     In addition, I actually do want to be able to create a "thing"
>     that is both a bf:Work and a bf:Instance -- why? Well, why not? If
>     I'm working with bibliographic data created in DCterms or
>     something simple like <>, I see no
>     reason why I cannot express that, for purposes of sharing, as:
>     :myThing
>       bf:instanceTitle [blah] ;
>       bf:creator [blah] ;
>       bf:subject [blah] ;
>       bf:publicationDate [blah] .
>     I also don't see a need to use rdf:type (or "a" in ttl) unless
>     those types provide necessary functionality. My impression is that
>     the primary use of rdf:type is to make data creators feel like
>     they've created a "record structure" or graph based on the type.
>     However, it's not the rdf:type but the identifier for the subject
>     that holds it all together, and any "thing" can be of more than
>     one type. The type, whether implicit or explicit, provides
>     semantics, not structure. My suspicion is that those semantics
>     will be rarely used because of the overhead of inferencing. At the
>     same time, I can see reasons, mainly having to do with the
>     cataloging function that FRBR was designed for, for wanting to
>     search and retrieve all bf:Work properties for a defined entity,
>     whether or not that entity has separate graphs for Works and
>     Instances. The best example of that would be combining data from
>     RDA and BIBFRAME, even though they have different definitions of
>     the bibliographic entities.
>     kc
>     -- 
>     Karen Coyle
>     [log in to unmask]  <mailto:[log in to unmask]>
>     m:+1-510-435-8234  <tel:%2B1-510-435-8234>
>     skype: kcoylenet/+1-510-984-3600  <tel:%2B1-510-984-3600>
> -- 
> Rob Sanderson
> Technology Collaboration Facilitator
> Digital Library Systems and Services
> Stanford, CA 94305

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