Bug 009: Vocabulary Terms are Not Reusable

public-earl10-comments@w3.org

This is feedback on a Last Call Working Draft:

Evaluation and Report Language (EARL) 1.0 Schema
W3C Working Draft 10 May 2011
http://www.w3.org/TR/2011/WD-EARL10-Schema-20110510/

The terms in the EARL vocabulary are defined in such a way which
prevents them from being seamlessly reused in other vocabularies. To
facilitate information sharing, and the enrichment of schemata in a
collaborative manner, make the terms in the EARL vocabulary reusable.

The problem is essentially one of too strict limitations on the
existing terms. Consider for example earl:assertedBy:

earl:assertedBy rdfs:domain earl:Assertion;
   rdfs:range earl:Assertor .

Or for the N3 illiterate:

<rdf:Description rdf:about="#assertedBy">
  <rdfs:domain rdf:resource="#Assertion"/>
  <rdfs:range rdf:resource="#Assertor"/>
</rdf:Description>

Now let's say I make a very similar vocabulary to EARL, but instead of
being for software tests it's for summarising the results of
proofreading. I might want to say that the results of this
proofreading session are assertedBy such and such, so it would be
natural to include the earl:assertedBy property in my vocabulary. But
it wouldn't be as sensible to include the earl:Assertion class, with
its strong emphasis on software testing.

The standard way to make a property like earl:assertedBy reusable like
this is to use owl:Restrictions. What an owl:Restriction can do is to
say that if you have earl:assertedBy as a predicate in a triple and
the subject is an earl:Assertion, then the object must be an instance
of earl:Assertor. In other words, it's a kind of local domain and
range constraint.

Then if I include earl:assertedBy into my own vocabulary, this
constraint will still apply. But since I won't be using earl:Assertion
instance as the subjects of earl:assertedBy, it's irrelevant. I can
add my own owl:Restrictions to earl:assertedBy instead. I might want
to reuse earl:Assertor for example, but use my own custom domain.

The extent to which this kind of reuse is allowed, whether extra
owl:Restrictions are allowed for example, should be specified in an
extensibility policy. Compare Bug 006 for details on that. In the case
of an owl:Restriction, it would probably be prudent to disallow
restrictions where the restricted domain and range are both from the
EARL namespace, and to allow anything else. Restrictions on the EARL
namespace would of course include classes subclassed from classes in
the EARL namespace.

There are other ways to promote reusability too. Register your terms
with a schema registry. Promote the vocabulary as being specifically
reusable. Give examples of where and how such a vocabulary might
indeed be reusable. These are important and logical things to do if
making a vocabulary reusable in technical terms as described above.

One argument against this being a bug, and for the existing order, may
be that RDF Schema is simple and OWL is complicated, and that this
increases the burden of understanding the specification. But the
quality of explanation is different from the intrinsic difficulty of
the technology. I hope, for example, that I have done a suitable job
in explaining extensibility here and how it can be achieved at least
in one important respect with restrictions (which is an unfortunate
misnomer because they are less restrictive than RDF Schema's domains
and ranges). If I can explain it here, then it can be explained in the
specification too.

Moreover, why does the W3C develop tools like OWL 2 if they're not
used when it's clearly appropriate to do so? So please use extensible
schema techniques for EARL.

-- 
Sean B. Palmer, http://inamidst.com/sbp/

Received on Tuesday, 10 May 2011 23:17:17 UTC