reflections on [comments on 28 April Working Draft of EARL Schema]

Dear group,

Please find below my reflections on the comments provided by Diego 
Berrueta on 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.

OK, I can ping Danbri and Libby. Don't think that this should stop us 
from a Last Call publication (we can drop it at any time).


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

Yes, I was wondering about this too. We should confirm and make this 
change as necessary.


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

Agreed, we would need better descriptions. That would be easy to fix but 
we need to address the subsequent comments too.


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

True, it complicates queries but has substantial benefits too.


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

I'm not sure what the difference is to the comment above. Anyone has a 
better idea of the "meta-modelling" impact?


> Consequently, our suggestion is to drop the five subclasses.

Before dropping this, I'd like to explore other options. I think that we 
implicitly use inferences between the classes and instances, and create 
confusion this way. If we can make it explicit, we may resolve these and 
the issues raised in the next comment too.


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

It is not uncomment to have SHOULD requirements in specifications but 
maybe we should look into how we can further tighten our statements.


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

This also relates to making inferences more explicit. If we can work 
this out, then we can address several areas of the specification.


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

Sounds like a good suggestion but I'd need help on this. We should 
confirm and look into how to best do this.


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

Perfectly sensible suggestion, which I think we should accept as-is.

CONCLUSION: implicit inferences and the structure of the OutcomeValue 
class need to be addressed for the upcoming Last Call publication (they 
are substantial changes). The other issues seem like easy fixes and can 
be addressed now or at a later stage.

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, 26 May 2009 21:42:31 UTC