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
BIBFRAME is not assuming that the work title and the
instance title are key "definers" of the entity, then that
>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
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.