- From: Ivan Herman <ivan@w3.org>
- Date: Wed, 30 Jun 2010 17:42:58 +0200
- To: Mark Birbeck <mark.birbeck@webbackplane.com>
- Cc: W3C RDFa WG <public-rdfa-wg@w3.org>
- Message-Id: <89D0B924-80D1-460E-8C4B-0F6DBF70F2A7@w3.org>
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
Attachments
- application/pkcs7-signature attachment: smime.p7s
Received on Wednesday, 30 June 2010 15:40:36 UTC