Re: EARL Schema resorted and with OWL constraints

Hi,

Thank you for the feedback Charles, please see some comments below:


Charles McCathieNevile wrote:
> Change 2 says "XML Instructions" - it should be "XML entities".

Fixed, thanks.


> 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.

Do you have suggestions for these combinations?


> 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.

Yes, we should remove them pretty soon but I suggest we keep them for now just for the sake of readability.


> 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).

Had a tough time with this one so as to not redefine foaf:Person. It say an earl:Assertor is either an earl:Tool a foaf:Person *with* specific attributes, not that a foaf:Person *has* specific attributes. Were do you see foaf:Person being redefined?


> 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.

Agreed. However, if we go on Recommendation track then we need to keep in mind that dependencies between different standards may be an issue. We need to monitor that.


> 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...

Agree with the minCardinality part (version info should be optional). However, how can a tool have more than one version? I suggest let's wait to see what Sandor finds, then we can reassess the constraints.


> 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.

We agreed in the requirements to formalize EARL so this rules out relying on descriptions in the spec. The text of the spec should be only clarification of what the RDF says. Having said that, we should try to minimize the requirements on EARL parsers/processors. So if we find a way to narrow down the range of such pointers *without* redefining the vocabulary, then I think we should.


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

Down-side is compatibility with plain RDFS. I'm still working on that one.


> 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 :-)

So that one too. Why not have heuristic *and* inference? We should discuss this in the group, I'm not really clear on how this property as a whole was taken up by tool developers. (I think it is useful information that could sometimes be a factor to influence the confidence)


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

Yes, I think this was raised several times before. Done.


> 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).

dc:description only has a minCardinality, not maxCardinality.


> 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.

Bad English. Changed word "concluded" to "suggested" to fix it.


> 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).

We had extensive discussion about it on the last teleconference, please see the summary posted to the list. Let's see what Nick comes up with, then we can reassess the impact.


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

Copy & paste typo. Fixed.


> 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.

This is already flagged. Let's refine the http-header stuff, then we can look back at the constraints. Currently this is the only thing that keeps WebContent actually different from TestSubject...


Regards,
  Shadi



-- 
Shadi Abou-Zahra,     Web Accessibility Specialist for Europe 
Chair and Team Contact for the Evaluation and Repair Tools WG 
World Wide Web Consortium (W3C),           http://www.w3.org/ 
Web Accessibility Initiative (WAI),    http://www.w3.org/WAI/ 
WAI-TIES Project,                 http://www.w3.org/WAI/TIES/ 
Evaluation and Repair Tools WG,     http://www.w3.org/WAI/ER/ 
2004, Route des Lucioles -- 06560, Sophia-Antipolis -- France 
Voice: +33(0)4 92 38 50 64           Fax: +33(0)4 92 38 78 22

Received on Friday, 10 June 2005 09:17:47 UTC