Bug 010: The mainAssertor Property is Aberrant

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/

This is feedback on ยง 3.6. mainAssertor Property:

http://www.w3.org/TR/2011/WD-EARL10-Schema-20110510/#mainAssertor

This property is weird in two respects. First, it is not constrained
from preventing an unbounded chain of main assertors. Second, it is
not constrained from loops. In other words, as far as I can tell both
of the following are allowed:

(1)

[ earl:mainAssertor [ earl:mainAssertor [ earl:mainAssertor [
earl:mainAssertor [ earl:mainAssertor [ earl:mainAssertor [
earl:mainAssertor [ earl:mainAssertor [ ... ] ] ] ] ] ] ] ] ].

(2)

:assertor01 earl:mainAssertor :assertor02.
:assertor02 earl:mainAssertor :assertor01.

Note that earl:mainAssertor is a sub property of earl:member. Of
course the EARL specification does not say what the range and domain
of earl:member are. They turn out to be domain foaf:Group and range
foaf:Agent. Furthermore, foaf:Group turns out to be a sub class of
foaf:Agent. So nothing in the above is inconsistent with FOAF either.

I'm not sure what to do about this exactly, but I think that
earl:mainAssertor is in this draft fundamentally broken. You can even
have this, technically:

(3)

:assertor01 earl:mainAssertor :assertor01.

I suppose I would need to know what the requirements were, and who
suggested that it would be not only a good idea but crucial to have an
earl:mainAssertor. This isn't so clearly an error with foaf:member
because the FOAF vocabulary is very sketchy to allow further
pencilling in. But EARL is a very strongly constrained vocabulary, at
least according to the current conformance criteria profile (though
compare Bug 004, and to some extent Bug 006), and yet
earl:mainAssertor leaves a very strange taste.

You can perhaps see this most clearly in my sketched diagram:

http://sbp.so/earl/diagram

That Assertor in the top middle could actually not exist, and the
earl:mainAssertor could have just been fed back into its parent
Assertor class, representing initially its domain of course, but here
subsequently its range, in a loop.

This was probably a good natured attempt to add utility to the
language, but I don't think it has been carefully thought out.

So in summary I'm at least proposing that the conformance criteria
should remove unbounded chains and loops from the use of
earl:mainAssertor. But I think a better solution would likely be in
the area of making an earl:Individual sub class of foaf:Agent, and
making that disjoint with foaf:Group. Then there could be an
owl:Restriction on earl:mainAssertor (taking careful note of Bug 009)
such that when it is used on an instance of foaf:Group, its object
must then be an instance of earl:Individual. The cardinality would be
zeroOrOne, in RELAX NG terms. The earl:mainAssertor property itself
might need some suitable renaming too.

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

Received on Tuesday, 10 May 2011 23:36:20 UTC