update #2 on [comments on 28 April Working Draft of EARL Schema]

Dear group,

Please find below the latest status with regard to the recent comments 
sent on the EARL 1.0 Schema:


Diego Berrueta wrote:
> FOAF
> ****
>  
>>From a technical point of view, we are not completely sure whether the
> semantics of foaf:Document are a perfect fit in the context of EARL.
> Apparently foaf:Document is designed for human-oriented documents, while
> validation usually applies to any kind of document (i.e., we believe
> that the semantics of foaf:Document is too narrow). Our suggestion is to
> contact FOAF editors to clarify the intended meaning of foaf:Document,
> to see, for instance, if it is intended to cover the XML representation
> of a human-oriented document, which can be two different subjects of
> validation.

Actually, foaf:Document is too broad and we need to narrow down the 
scope of our use of this term in the context of EARL. A suggestion is 
archived on the list:
  - <http://lists.w3.org/Archives/Public/public-wai-ert/2009Jun/0000>


> DUBLIN CORE
> ***********
>  
> The use of the old dc: namespace is not advised in new applications. We
> suggest to use exclusively the dct: namespace, which replaces and
> extends the obsolete dc: namespace (see the last paragraph of
> http://dublincore.org/documents/dces/ : "Over time, however,
> implementers are encouraged to use the semantically more precise
> dcterms: properties")

Correct, we should change. The namespace for all Dublin Core terms is:
  - <http://dublincore.org/documents/dcmi-terms/>


> CLASS-INSTANCE DUALITY
> **********************
>  
> Section 2.7 defines 5 subclasses of earl:OutcomeValue, and a prototype
> instance of each of these subclasses. We have some comments regarding
> these subclasses and instances:
>  
> 1) The textual definitions of the instances (e.g., earl:passed) and the
> subclasses (e.g., earl:Pass) are identical. Therefore, it follows that
> they share the very same conceptual space. Consequently, these singleton
> instances are also the only ones possible of their kind, i.e., it is
> impossible to conceive an instance of earl:Pass different from
> earl:passed.
>  
> 2) The duality introduces unnecessary confusion. For instance, under
> which condition two tests have the same outcome value? Intuitively, they
> have the same outcome if they have the same value (resource) for their
> respective earl:outcome properties (e.g., earl:failed, earl:passed...).
> However, under the duality, the values cannot be directly compared, as
> they could be two different instances of the same subclass (earl:Fail,
> earl:Pass...). This greatly obfuscates any SPARQL query on the report.
>  
> 3) The duality introduces confusion on the use of meta-modelling. For
> instance, which one of the following is correct?
>  
>    a) ex:myTestResult1 earl:outcome earl:passed .
>    b) ex:myTestResult2 earl:outcome earl:Pass .
>  
>    In RDF, there is enough syntactic freedom to use any of these
> statements. Unfortunately, this freedom makes it more difficult to
> compare the results of two tests, because they do not have the same
> ontological status. Moreover, the latter option turns into a problem if
> the report is to be interpreted as OWL-DL, because it introduces
> meta-modelling.
>  
> Consequently, our suggestion is to drop the five subclasses.

After looking at this closely, it seems that the basic issue is the 
(textual) definition for each of the terms. We need to find clearer 
definitions like:

  * earl:Pass - the class of all positive outcome values
  * earl:passed - an instance of passing a test requirement

This is still not optimal wording but the idea is to show that other 
instances could belong to the overall class of "Pass". For example, 
earl:passedWithExcellence could be a further refinement that is not 
"native" to EARL. We would also need additional clarifications in the 
Guide document.

If other agree, I could take a shot at different definitions.


> CONFORMING REPORTS
> ******************
>  
> We have two comments with respect to the Conforming Reports (Section
> 4.1):
>  
> 1) From our point of view, it is not clear enough how "SHOULD"
> requirements are to be interpreted. Which are the precise conditions
> under which a report passes or fails a SHOULD requirement? It seems to
> us that these kind of requirements have little use in practice, and
> consequently, we suggest to drop them.

We need more careful consideration of this. I suggest we continue this 
discussion, possibly after the upcoming Last Call publication.


> 2) It is not clear whether the conformance requirements must take into
> account the RDF(S) semantics. For instance, is the following report
> valid wrt requirement 2?
>  
>     ex:assertion rdf:type ex:MyAssertionClass .
>     ex:MyAssertionClass rdfs:subClassOf earl:Assertion .
>  
> Strictly speaking, there isn't any earl:Assertion in the report.
> However, RDF(S) Semantics dictate that the triples above entail
> (ex:assertion, rdf:type, earl:Assertion), thus making the requirement
> pass.
>  
> We suggest to explicitly clarify whether the RDF(S) entailment rules
> must be applied before checking the conformance rules.

I think that part of the issue is that we use the wording "referenced 
by", and point to specific classes. For instance:

* "Every Assertion must have exactly one Assertor (referenced by 
earl:assertedBy)"

Here an attempt at refining this wording (as suggested by Diego):

* "Every Assertion must have exactly one Assertor (an Object of 
earl:assertedBy)"

Is this correct, and is it what we want?


> RDF REPRESENTATION OF EARL
> **************************
>  
> In the RDF description of the EARL ontology, please consider using OWL
> constructors such as owl:Class. Note that it is not our suggestion to
> drop the RDF/RDFS constructors (such as rdfs:Class), which should be
> preserved. Our suggestion is to add the OWL constructors in addition to
> the current ones. Using both sets of constructors is harmless and cheap
> (it just adds a few triples), but enables both the OWL-aware and the
> RDFS-aware applications (graphical ontology editors, reasoners, etc.) to
> seamlessly operate with the EARL ontology.

As per my previous mail, I suggest that we accept this suggestion and 
work on such additions:
  - <http://lists.w3.org/Archives/Public/public-wai-ert/2009Jun/0003>


> Additionally, please consider adding a direct link to the RDF
> description of the EARL ontology from the HTML document. See for
> instance the "(rdf)" links at the top of the FOAF HTML document at
> http://xmlns.com/foaf/spec/ .

As per our previous discussion, we should do this for all our specs.


Regards,
   Shadi

-- 
Shadi Abou-Zahra - http://www.w3.org/People/shadi/ |
   WAI International Program Office Activity Lead   |
  W3C Evaluation & Repair Tools Working Group Chair |

Received on Tuesday, 2 June 2009 22:35:26 UTC