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.


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, I see no reason why I cannot express that, for purposes of sharing, as:

  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.

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

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