Print

Print


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