Re: On ISSUE-26 : RDFa Error vocabulary

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

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

Received on Wednesday, 30 June 2010 15:23:33 UTC