On Thu, Nov 6, 2014 at 12:53 PM, Karen Coyle <[log in to unmask]> wrote:
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.

Sure. So why would those communities that do not follow bibframe then decide that they should (a) use bibframe and (b) use it incorrectly?

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, schema.org, 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.

And presumably they would then have to mint new identifiers to distinguish the Work from the Instance, if they wanted to actually use bibframe.
 
(Note that a lot of work is going into making citations linkable, e.g. at PLOS.)

Using bibframe? I would guess not.
 

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

I don't buy the argument that people who are intending to follow a different model will suddenly require the same resource to be both an abstract concept and a physical thing at the same time.  They simply wouldn't use bibframe, the same way that bibframe doesn't use schema.org or bibo.

 
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.

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

+1 to not asserting restrictive domains on predicates that imply impossible class combinations, to allow allied communities to work with us even though they have slightly different modeling requirements.

;)
 
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.

Yes ... and that is explicit types and not requiring inferences based on specific domain knowledge.

Rob
 

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]> 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 schema.org, 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] http://kcoyle.net
m: +1-510-435-8234
skype: kcoylenet/+1-510-984-3600



--
Rob Sanderson
Technology Collaboration Facilitator
Digital Library Systems and Services
Stanford, CA 94305

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



--
Rob Sanderson
Technology Collaboration Facilitator
Digital Library Systems and Services
Stanford, CA 94305