Proposed changes

Hi folks,

some comments (sorry to be so close to the call)

Properties of assertions:

[[[
<rdf:Property rdf:about="&rdf;ID" rdfs:label="ID">
      <rdfs:domain rdf:resource="&earl;Assertion"/>
      <rdfs:range rdf:resource="&rdf;Literal"/>
</rdf:Property>
]]]

This is a bad idea - it is an attempt to define the rdf ID property. Which  
we absolutely shouldn't do. If we want to require an ID on an assertion  
(and I think this isn't necessarily a good idea either) this isn't the way  
to do it...

[[[
<rdf:Property rdf:about="&earl;location" rdfs:label="location">
      <rdfs:subClassOf rdf:resource="&rdfs;Container"/>
      <rdfs:domain rdf:resource="&earl;Assertion"/>
      <rdfs:range rdf:resource="&earl;Location"/>
</rdf:Property>
]]]

Makes good sense to me. But I think the URIs of the property ....#location  
and the class ...#Location should be more obviously different even for  
people who are editing code and therefore should know what they are doing.

[[[
<rdf:Property rdf:about="&earl;evidence" rdfs:label="evidence">
      <rdfs:subClassOf rdf:resource="&rdfs;Container"/>
      <rdfs:domain rdf:resource="&earl;Assertion"/>
      <rdfs:range rdf:resource="&earl;Assertion"/>
</rdf:Property>
]]]

I think the evidence property is a good idea. I don't think the range  
should be an Assertion - mostly because I would like to also be able to  
point to a rule that describes how several results relate to each other,  
and this is likely to be an OWL Restriction that is not, in itself, an  
EARL assertion. (Where an assertion is a result declaration - we have  
talked about minimal assertions having an assertor, date, subject,  
testcase... and this would make that pretty difficult).

Properties of Assertor...

I would drop all of the ones that relate to people, in favor of using  
foaf:Person (there are lots of unstable bits of foaf, but the ones we want  
are among the most-used RDF properties in existence and I think they are  
fairly reliable...). For tools, I suggeest that we start with dc:title,  
and maybe some other DC stuff, but that we look for an existing  
description vocabulary rather than making up our own. Somethign like  
Bugzilla might be a good place to look.

Properties of TestSubject...

again, we should not define Dublin Core properties here. We should, in the  
spec, show how they are used in EARL (ditto for the FOAF stuff above). I  
would like to discuss the use of earl:reprOf, because I think it should  
have a range of WebContent, and that should have the properties like GET  
request headers, returned headers, body and so on. I also think we should  
talk to the Annotea folks directly and ask what they think of the idea of  
re-using their terms (a:body seems a shoe-in. Their HTTP vocabulary is  
undocumented, but we might be able to get them to document it instead of  
doing it ourselves. Failing which, there is probably another one out there  
that is well documented.

Properties of TestResult...

I am not sure that a message is really a description of a resource, which  
is what DC description means. Apart from the fact that it is a very  
abstract resource, sometimes the message is a description and sometimes  
not. I am also not clear about the relationship between confidence and  
precision - I think that we still need to discuss that further. My  
suggestion is actually to use a datatype to deal with refinements on  
confidence, since it is such an unknown quantity anyway. Then we can use  
whatever BPWG figures out makes sense as a way of relating between  
datatypes.

Properties of Location...

I would not rush to add these without figuring out what we want. Maybe  
line number because it is really common, but it needs to be well defined  
(count from 0 or 1? what about blank lines? CR/CRLF/LF all count the same?  
etc).

cheers

Chaals


-- 
Charles McCathieNevile                              chaals@opera.com
                  se habla español - nous parlons français
   Here's one we prepared earlier:   http://www.opera.com/download

Received on Tuesday, 3 May 2005 15:43:19 UTC