Re: EARL Schema resorted and with OWL constraints

On Thu, 09 Jun 2005 16:39:52 +0200, Shadi Abou-Zahra <shadi@w3.org> wrote:

> Ref: <http://www.w3.org/WAI/ER/EARL10/schema.html>
>
> While adding OWL constraints to the EARL Schema, I found myself  
> resorting the current break-down of Class - Property - Instance.

I'm not fussed about the ordering - whatever makes it easy to edit works  
for me, and in any case a little SPARQL dust could be used to get a  
different order if you wanted it.

A couple of comments on that document ranging from the trivially editorial  
to more structurally significant...

In the section on Document Header:

Change 2 says "XML Instructions" - it should be "XML entities".

Assertor:

I am not sure that we should be setting a maximum cardinality on the  
properties of Assertor. We might want to block certain pairwise or n-ary  
combinations, but I think there are good use cases for being able to have  
more than one of many properties.

Here (and further on) you have used XML entities again. It's clear what  
you mean, but we should take them out when we draft the actual schema,  
following the decision above.

I don't think we should make OWL constraints on foaf:Person. It's  
anti-social behaviour to redefine someone else's terms (albeit not  
actually technically wrong in any way). If we really want to insist on  
some properties we should subclass foaf:Person to do it, but I don't   
think that we need to do that. We could note in a comment on the Assertor  
class that we expect it to be a foaf:Person identified with a name as well  
as an mbox or mbox_sha1sum (which is actually more normal in foaf these  
days as a way to protect from spammers trawling it).

Stability of FOAF needs to be verified: the parts we use (Person, name,  
mbox / mbox_sha1) are about the most stable parts there are, and seem very  
unlikely to change for any practical purpose (although name might allow  
complex names in some compatible way). In any event Opera is seperately  
going to request that there is a bit more stability in the core of FOAF.

Tool:

I don't think we should have maxcardinality on versioning info, and  
probably not mincardinality either. In some cases we will want to have a  
tool which just has a name, and other cases we will want a tool the  
isVersionOf that tool...

Again, we should not specify domain/range constraints on DCs terms. I  
don't think we need to make our own. In the spec we should just have  
examples of how thesee ought to be used in EARL.

TestMode:

I am happy if the instance values are only defined in OWL, since that is  
(IIRC) inheritable via RDFS.

The label on heuristic should be "inference" since that is what it  
actually is. But I see no need to change the property name since that just  
multiplies the number of properties that are out there to no useful effect  
(unless forcing EARL parsers to implement owl:sameAs is useful. I think it  
will become a necessary evil one day, but I don't feel a need to rush  
there :-)

TestResult:

We should definitely have minCardinality of 0 for confidence (i.e. it is  
optional).

I think it is reasonable to have it for dc:description as well. We should  
not ahve a maxCardinality - for example in teh development plan of Hera we  
will be putting multiple descriptions on automated tests, to label in  
different languages (since it is a multilingual tool).

ConfidenceLevel:

I think the description is wrong - I don't think there was consensus that  
confidence was a proprty of the test rather than of the result, but that  
it was related to many different factors including the way the test was  
run.

I am strongly against requiring that it be on of the specified values - I  
think it should be open since I still believe that we are going to find  
more than three useful values, and the difficulty is in fact in getting  
meaningful interoperability, not in being able to use the same set of  
terms (which would appear to be interoperable but would, I argue mean in  
practice that there was much less interoperability than we might otherwise  
expect).

TestSubject

The current proposal has TestSubject being WebContent, which I think is  
unliekly to be what you were thinking :-)

I don't think we should constrain WebContent much at all - especially at  
this stage. We should note that we want to be able to describe lots of  
things about it and haven't yet got a vocabulary that we will use... (yay  
for drafts :-)

WebContent:

see remarks above. I don't think we should constrain http-header to be  
Literal until we have some idea of what we expect it to be like. It makes  
a lot of sense to me that it is in fact a collection of properties, one  
per header. And that we ask for comments on approrpiate vocabularies as  
part of the review call for the draft.

Anyway, good stuff - keep it up :-)

cheers

Chaals


-- 
Charles McCathieNevile                              chaals@opera.com
          hablo español - je parle français - jeg lærer norsk
   Here's one we prepared earlier:   http://www.opera.com/download

Received on Friday, 10 June 2005 01:31:08 UTC