On Thu, Nov 06, 2014 at 03:12:47PM -0500, [log in to unmask] wrote:
> It is possible to make inference a requirement for Bibframe applications,
> but I agree with Rob Sanderson: that would be a mistake. 

I find the Type thread confusing to follow and wonder if we share basic
assumptions.  In RDF, as I understand it, declaring classes has two
purposes:

1) (formally) to support inferencing, e.g., when used with
   rdfs:domain, rdfs:range, or rdfs:subClassOf;

2) as informal labels for types of things.

Once a class is declared to have an rdfs:subClassOf relation to another
class, that declaration becomes part of the formal semantics of the
class.  Once a property is related to a class through rdfs:domain and
rdfs:range, that declaration becomes part of the formal semantics of the
property.  Whether membership of an instance in a domain or range class
is _asserted_ in a given dataset, or _inferred_, is purely a practical
question having to do with things like "expense," "response time", or as
Simeon points out, whether it "make[s] the data easy and efficient to
use" or provides "clarity of intent" to someone trying to grok the
Turtle data.  Simply leaving a formal-semantic relationship unasserted,
to be clear, has no affect on formal semantics.  

I do not understand the point of coining lots of new classes for the
BIBFRAME vocabulary.  An RDF vocabulary cannot itself provide ways to
prevent "multiple, incompatible ways" of using the vocabulary, which I
take to be Rob's objective.  If data consistency, clarity of intent (for
humans), and efficiency of processing are indeed the objectives, I do
not understand why the discussion here is about trying to do this in
BIBFRAME's RDF vocabulary, which does not provide the language for
exerting such control.

Rather, I had always understood such control to be the point of BIBFRAME
profiles [3].  As Karen points out, RDF does not provide a way to say
that a property is defined "for" a class in the manner of CWA-based
applications, but profiles do.  Jeff helpfully suggests that
Schema.org's looser notions of domain and range may be appropriate here
[1,2].  To take one example, if it is desirable to assert class
membership explicitly, this could be enforced in a profile with a
mandatory statement template -- without making the vocabulary any more
complex than it needs to be.

In short, I do not understand why this discussion is all about the
BIBFRAME vocabulary, and its classes, and not about the more practical
question of specifying the description of class instances with BIBFRAME
profiles.

Tom

[1] http://schema.org/rangeIncludes
[2] http://schema.org/domainIncludes
[3] http://www.loc.gov/bibframe/docs/bibframe-profiles.html


-- 
Tom Baker <[log in to unmask]>