Re: On ISSUE-26 : RDFa Error vocabulary

So... (just in time for the telco)

First of all, I looked at the Earl and related documentation again, and then had a chat with Shadi Abu-Zahra, who is the staff contact in the relevant group and also co-editor of EARL.

First of all, EARL is in second last call. This means that while it is possible to have some editorial changes in the document, he does not think it is possible to make substantial changes, eg, changing attribute and class names. Then we went through the issues and we agreed that some classes (eg, assertor, assertion) could be used for error handling purposes while slightly changing the text description of those classes (it currently says, for Assertion "a statement that embodies the results of a test." But we also agreed that the term 'test' does not really apply for what we do in RDFa and, unfortunately, the terms used for most of the properties and classes do refer to tests all over the place. Not only the class and property names often refer to tests (TestResult, TestSubject, test,...) but the properties have range and domain definition that often refer to these classes, ie, by using them, we would assert certain classes to be, say, Test results, when in reality they aren't.

What I did is to go again through all these documents and changed what we have. It is on the wiki, to make it quicker, it is reproduced here (also using some of Mark's example):

<#assertor> a earl:Assertor, earl:Software, foaf:Agent ;
   foaf:name "RDFa Distiller" ;
   dc:description "RDFa Distiller Service" ;
   foaf:homepage <http://www.w3.org/2007/08/pyRdfa/> ;
   dc:hasVersion "2.3.5" .

[] a earl:Assertion ;
   earl:assertedBy <#assertor> ;
   rdfa:subject <http://www.example.org> ;
   rdfa:error [
       a rdfa:ProfileReferenceError ;
       dc:description "The @profile value could not be deferenced" ;
       dc:date "2010-06-30T13:40"^^xsd:dateTime ;
       rdfa:onUri <http://www.example.org/profile> ;
       rdfa:pointer [
           ptr:reference <http://www.example.org> ;
           # if exact pointer information can be provided here...
       ]
   ] .
  
I used the pointer from Mark's example, though I am not sure this could be universally used. Eg, my distiller runs a DOM parser on the source, so the line and character number is completely lost by the time error is managed.

The rdfa specific properties are needed to replace their earl equivalents but without a range/domain specification; here is the schema:

rdfa:Error  rdfs:subClassOf earl:OutcomeValue .

rdfa:ProfileReferenceError rdfs:subClassOf rdfa:Error .

# More classes come here...
rdfa:error a owl:objectProperty ;
    rdfs:domain earl:Assertion ;
    rdfs:comment "much like earl:result, but is range is not TestResult"

rdfa:subject a owl:objectProperty ;
    rdfs:comment "much like an earl:subject, but its range is 
     not set to be a test subject" ;

rdfa:pointer a owl:objectProperty ;
   rdfs:comment "much like earl:pointer, but its domain 
     is not set to TestResult" .

B.t.w., I agreed with Shadi that he would look at the RDFa vocabulary when we think it is closer to final.

Ivan


On Jun 30, 2010, at 18:01 , Mark Birbeck wrote:

> Hi Ivan,
> 
>> Well, I do not agree with that. Running a retrieval service is not conceptually
>> a validation for me. If a @profile is temporarily down, because, say, its holder
>> machine is down, that this is not a validation error at all, it is a temporary
>> network of hardware problem that does affect the graph you get at a moment
>> it time which is otherwise perfectly valid. EARL is made to the management
>> of tests and their results; that has nothing to do in my view with what we are
>> discussing here...
>> 
>> I am absolutely not pushing for our own vocabulary for the purpose of having...
>> our own vocabulary. But I have not found anything used for our own purposes.
>> I do not believe EARL is appropriate.
> 
> I have to say I'm surprised that you say this. :)
> 
> EARL is so close to what we're defining here that it was pretty much
> made for the job! It may lack some precision in the terminology, but
> we have choices there. We could:
> 
> * live with the slight lack of precision;
> * sub-class from the terms we don't like, to create something more accurate;
> * work with the 'EARL community' to add additional terms that address parsing.
> 
> Each of these options is preferable to creating a bunch of new terms
> that don't really have any essential organising principle.
> 
> Anyway, I guess we can discuss this on the telecon, but I'm really
> against the vocabulary explosion that seems to be underway here; even
> if we don't like EARL, we should still try to use more FOAF and DC so
> as to keep to a minimum the number of terms that need to be invented.
> 
> Regards,
> 
> Mark
> 
> --
> Mark Birbeck, webBackplane
> 
> mark.birbeck@webBackplane.com
> 
> http://webBackplane.com/mark-birbeck
> 
> webBackplane is a trading name of Backplane Ltd. (company number
> 05972288, registered office: 2nd Floor, 69/85 Tabernacle Street,
> London, EC2A 4RR)


----
Ivan Herman, W3C Semantic Web Activity Lead
Home: http://www.w3.org/People/Ivan/
mobile: +31-641044153
PGP Key: http://www.ivan-herman.net/pgpkey.html
FOAF: http://www.ivan-herman.net/foaf.rdf