- From: Charles McCathieNevile <chaals@opera.com>
- Date: Tue, 03 May 2005 17:43:00 +0200
- To: "public-wai-ert@w3.org" <public-wai-ert@w3.org>
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