 |
 |
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 [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