- From: Dominique Hazael-Massieux <dom@w3.org>
- Date: Thu, 10 Dec 2009 10:16:34 +0100
- To: public-earl10-comments@w3.org
- Cc: ERT WG <public-wai-ert@w3.org>
Hello, Le mardi 08 décembre 2009 à 10:32 +0100, Shadi Abou-Zahra a écrit : > EARL 1.0 has been published as Last Call Working Draft and the working > group welcomes input, including acknowledgment that previous comments > have been adequately resolved, by *Monday 21 December 2009* to: > - <public-earl10-comments@w3.org> > > This publication includes: > * Evaluation and Report Language (EARL) 1.0 Schema - Last Call Working > Draft > - <http://www.w3.org/TR/EARL10-Schema/> I have only reviewed that document for the time being; I’m not sure I will have time to review the 3 others (presumably) normative documents (Content-in-RDF10, HTTP-in-RDF10, Pointers-in-RDF10) before December 21st. I think the overall modeling presented in EARL10-Schema seems sound, but I’m not an RDF-modeling expert. I haven’t seen the publication of these documents and the request for feedback sent to semantic-web@w3.org — I think they definitely should. I think I understand what the combination of instances and classes in section 2.7 OutcomeValue is about, but I’m sure an example showing when and how you would use the classes would be useful. I definitely support re-using the terms from DOAP, since it’s one of the RDF vocabularies that are in wide use at this time. On the conformance section: I would recommend only defining conformance classes that are relevant to that particular document in the section (i.e. EARL core *); but I think the best solution would be to separate the semantic definitions (the schemas) from the conformance expectations into a separate document (EARL10-reports presumably). I think it’s bad form to use conformance requirements keywords (MUST etc) on documents — they ought to be used for agents only (i.e. consumers and producers); see my reasoning in http://lists.w3.org/Archives/Public/public-mwts/2009Dec/att-0006/extracting-test-assertions-pub.html#making-the-specification---testable In practice, instead of saying “EARL Reports conforming to EARL 1.0 Core must meet the following requirements” I would phrase it as: A conforming EARL report is an RDF graph with: • at least one earl:Assertions, • … This doesn’t allow to use the equivalent of SHOULD, but I don’t think they make much sense for reports — they really are requirements for producers. I think it would be useful to provide an OWL ontology that asserts they said constraints in a machine readable format. I’m not sure why you make a SHOULD requirement for consumers and producers to support other RDF serializations, esp. without listing them. I think the requirements that producers MUST generate reports with all information available to it is likely unreasonable, and probably not very useful; maybe making it a SHOULD would help. The requirements for consumers to “process” EARL reports seem pretty vague; are consumers expected to do some amount of entailment for instance? Dom
Received on Thursday, 10 December 2009 09:17:05 UTC