Re: On ISSUE-26 : RDFa Error vocabulary

On Jun 30, 2010, at 17:22 , Mark Birbeck wrote:

> Hi Ivan,
> 
> I really don't see why we need to invent a new vocabulary/ontology for
> this when something very close already exists.
> 
> On your point about EARL being more to do with testing, I don't think
> that's a problem, firstly because I think that it addresses much
> broader concerns than just testing, but secondly because I think
> validation can easily be cast in the language of testing anyway.
> 
> (You can regard 'parsing plus error-reporting' as conceptually the
> same as 'validation plus parsing'. I.e., even though we don't have to
> run validation as a separate step, it could conceptually be regarded
> as a separate step, and therefore regarded as a set of tests against a
> document.)
> 

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. 

Ivan

P.S.
We could, however, using dc:date instead of the timestamp. I find the name of the predicate (date) a bit misleading, but 

http://dublincore.org/documents/dcmi-terms/#terms-date

does say

[[[
A point or period of time associated with an event in the lifecycle of the resource.
]]]

but its range is defined to be Literal, and not restricted as dateTime.


> What I like about treating validation this way is that if you wanted
> to you could switch a 'validator' into 'verbose' mode and get back not
> only failed 'tests' but those that passed, as well -- effectively
> providing a parsing log.
> 
> So, let's take a scenario. We want to use Distiller to parse/validate
> the URL used in your examples:
> 
>  <http://www.example.org>
> 
> EARL describes the document to be validated as a 'test subject', so
> the first thing to do is express the document that way:
> 
>  <http://www.example.org>
>    a earl:TestSubject ;
>    dct:date "2010-06-30T13:40"^^xsd:dateTime
>    .
> 
> EARL allows us to add other things to this TestSubject object, such as
> related documents, a description, and so on.
> 
> Next, we might want to indicate what software did the parsing.
> 
>  <#assertor>
>    a earl:Assertor ;
>    dct:title "Distiller" ;
>    dct:description "RDFa Distiller and Parser ;
>    foaf:homepage <http://www.w3.org/2007/08/pyRdfa/> ;
>    dct:hasVersion "2.3.5"
>    .
> 
> The test requirements can be expressed either at a detailed level (as
> test cases), or at a high level (as requirements). One of the EARL
> documents gives 'conforming to XHTML' as an example of a high level
> requirement, so we might decide that there is only one requirement per
> parse/validate run, and that's 'to conform to RDFa 1.1' (or 1.0):
> 
>  <http://www.w3.org/TR/rdfa-core/>
>    a earl:TestRequirement ;
>    dct:title "RDFa 1.1 Core" ;
>    dct:description "Conforming to RDFa 1.1 Core"
>    .
> 
> (As it happens, it would actually need to be 'RDFa 1.1 + HTML 5' or
> '... + SVG' or whatever. But you get the picture.)
> 
> Alternatively, we might map some of the test cases in the RDFa test
> suite, and use those.
> 
> Finally, after defining the requirements, we need some validation
> results. In EARL these are packaged up as:
> 
> * an assertion about some test that has been run...
> * ...against some test subject (recall that this was the document
> being parsed)...
> * ...carried out by some software or person (in our case, a parser/validator).
> 
> The result of trying this assertion on the test subject is a test
> result. An example of the whole package (assertion plus result) is
> here:
> 
>  <#assertion01>
>    a earl:Assertion ;
>    earl:result [
>      a earl:TestResult ;
>      earl:outcome <http://www.w3.org/ns/earl#failed> ;
>      dct:title "Profile failed to load" ;
>      dct:description "A URL in @profile must refer to a loadable profile ...
>        ... or a profile that the parser has special knowledge of." ;
>      earl:pointer <#pointer> ;
>      earl:info "The remote profile at
> 'http://www.example.org/profile' failed to load, and no local version
> was available."
>      .
>    ] ;
>    earl:test <http://www.w3.org/TR/rdfa-core/> ;
>    earl:subject <http://www.example.org> ;
>    earl:assertedBy <#assertor>
>    .
> 
> By the way, the earl:pointer part can not only be a line number plus a
> character offset, but it can also be an XPath expression. A simple
> example would be:
> 
>  <#pointer> ptr:LineCharPointer ;
>    ptr:lineNumber "15" ;
>    ptr:charNumber "5" ;
>    ptr:reference <http://www.example.org/resource/content_001#content1a>
>    .
> 
> As you can see, I haven't invented a single class or predicate, and
> we've got nice reuse of FOAF and DC into the bargain. Using EARL we
> also don't have to keep adding new error classes whenever we decide we
> need a new type of error. And a final bonus is that EARL comes
> complete with a way to describe the parser that generated all of these
> errors.
> 
> If however you feel that you'd like some of the terms to be more
> precise, I'd suggest that you subclass from EARL, rather than making
> up new, unrelated, terms. (Or even better, appeal to the EARL-owners
> to add more generic features for validation.)
> 
> 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)
> 
> 
> On Wed, Jun 30, 2010 at 1:59 PM, Ivan Herman <ivan@w3.org> wrote:
>> Tracker, this closes ACTION-33
>> 
>> As agreed, I have created a first stab at the error vocabulary, see
>> 
>> http://www.w3.org/2010/02/rdfa/wiki/Error_vocabulary
>> 
>> I looked at EARL, as Mark suggested, but the EARL vocabulary is really geared at testing. I do not think it is appropriate.
>> 
>> I was also wondering how to put a reference to the problematic (DOM) node into the error message, but I do not really know how. It is of course possible to mint an XPATH URI for that, but that would be quite a load on implementers, so I would prefer not to do that. Otherwise the only thing we could do is to add a string with the node name, but that is hardly informative enough. There is a rdfs:comment field whose content is undefined, applications may find better tricks for that...
>> 
>> At the moment, I have defined only one Error class, for the @profile issue. Shane has just referred to some others related to the CURIE/relative URI discussion that should be added, too.
>> 
>> Thoughts?
>> 
>> Cheers
>> 
>> Ivan
>> 
>> ----
>> 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
>> 
>> 
>> 
>> 
>> 
>> 


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