W3C home > Mailing lists > Public > w3c-rdfcore-wg@w3.org > September 2001

Re: Testing and manifest.rdf (fwd)

From: Jan Grant <Jan.Grant@bristol.ac.uk>
Date: Thu, 27 Sep 2001 10:16:09 +0100 (BST)
To: RDFCore Working Group <w3c-rdfcore-wg@w3.org>
Message-ID: <Pine.GSO.4.31.0109271008310.8265-100000@mail.ilrt.bris.ac.uk>
OK, I've got a billion things to try to tie up, but as Art requested...

There's a brief, slightly more articulate discussion of this at
	http://ioctl.org/rdf/test/
- but discussion of this on #rdfig got me thinking about what it means
to be a literal again. (DanC: third options smells bad. Not sure why).

In an attempt to make everything smell of roses, I'm going to try to
produce some words about literals by the end of the day, with a view to
comparing the points of view on Friday.

jan

-- 
jan grant, ILRT, University of Bristol. http://www.ilrt.bris.ac.uk/
Tel +44(0)117 9287088 Fax +44 (0)117 9287112 RFC822 jan.grant@bris.ac.uk
Leverage that synergy! Ooh yeah, looking good! Now stretch - and relax.

---------- Forwarded message ----------
Date: Wed, 26 Sep 2001 10:52:39 -0400
From: Art Barstow <barstow@w3.org>
To: Jan Grant <Jan.Grant@bristol.ac.uk>
Subject: Re: Testing and manifest.rdf (fwd)

Jan - would you please forward or re-send this note to the WG?

Thanks,

Art
---

On Tue, Sep 25, 2001 at 02:32:13PM +0100, Jan Grant wrote:
> Here's the crux of what I wrote...
>
> simple syntax pulls against the need to not commit the same sins we keep
> railing about.
>
> I think it'll probably look like this:
>
> <test:ParserTest>
> 	<test:name>...</test:name>
> 	<test:description>...</test/description>
> 	<test:inputRDFDoc1>
> 		<test:RDFDoc rdf:about="url-of-original-test(ie, base uri)">
> 		  <test:localInstance rdf:resource="file:path-within-zip"/>
> 		</test:RDFDoc>
> 	</test:inputRDFDoc1>
> 	<test:resultingNtriplesDoc>
> 		<test:NtriplesDoc rdf:about="url-of-original-test(ie, base uri)">
> 		  <test:localInstance rdf:resource="file:path-within-zip"/>
> 		</test:NtriplesDoc>
> 	</test:resultingNtriplesDoc>
> </test:parserTest>
>
> --
> jan grant, ILRT, University of Bristol. http://www.ilrt.bris.ac.uk/
> Tel +44(0)117 9287088 Fax +44 (0)117 9287112 RFC822 jan.grant@bris.ac.uk
> Prolog in JavaScript: http://tribble.ilrt.bris.ac.uk/~cmjg/logic/prolog-latest
>
> ---------- Forwarded message ----------
> Date: Tue, 25 Sep 2001 11:30:41 +0100 (BST)
> From: Jan Grant <Jan.Grant@bristol.ac.uk>
> To: Art Barstow <barstow@w3.org>
> Cc: Aaron Swartz <aswartz@upclink.com>,
>      Dave Beckett <dave.beckett@bristol.ac.uk>,
>      Jeremy Carroll <jjc@hplb.hpl.hp.com>,
>      jos.deroo.jd <jos.deroo.jd@belgium.agfa.com>
> Subject: Testing and manifest.rdf
>
> As the bunch of people who seemed most interested in the testing aspects
> at the last telecon, I thought I'd poll you all about this.
>
> Dave B's got a schema for describing the results of parser tests here:
> http://ilrt.org/discovery/2001/03/parser-tests/
> (schema is at http://ilrt.org/discovery/2001/03/parser-tests/schema.rdfs )
>
> but we really need something a little more general.
>
> Tests seem to really be boolean functions of a set of inputs; the inputs
> in question are generally pieces of RDF (or ntriples). Tests we've got
> thus far are:
>
> positive parser test ( rdf document, ntriples document )
> 	succeeds if the rdf document parses to produce an rdf model
> 	equivalent to that specified by the ntriples document
>
> negative parser test ( "nrdf" document )
> 	succeeds if the document is rejected as being illegal rdf
>
> and suggested tests are also:
>
> positive entailment test ( doc1, doc2 )
> 	succeeds if the rdf in doc1 entails that in doc2
>
> negative entailment test ( doc1, doc2 )
> 	succeeds if doc1 and doc2 are legal rdf but doc1 doesn't
> 	entail doc2.
>
> - I think Jeremy has some other test types he'd ilke to include.
> It's worth pointing out that not every input to a test has to be a
> document (it could be a literal, such as Dave B's "number of statements
> produced").
>
> This is all pretty straightforward, and doesn't have to be overly
> complicated; a manifest file can just list a whole bunch of tests one
> after another (ie, we don't need to tie them up in a sequence or other
> container).
>
> However, there is a problem that crops up principally during parser
> tests: some of the RDF/XML parser tests assume (and exercise) a given
> base URI for the document (those involving rdf:id in particular). But
> we're intending to ship these tests as a ZIP file, so we need to give a
> local addres for the test too.
>
> So to describe a single input we need to give:
>
> - type of document (rdf/xml, ntriples, etc)
> - base URI of document (if applicable)
> - relative path to instantiation of document
>
> And these lead to stylistic issues.
>
> First: we can have the URI of the resource describing an input actually
> _be_ the base URI of the document.
> Alternatively, we can have some other URI for the document (or keep it
> anonymous) and hang a property off it giving the address of the
> "canonical instantiation".
> In this latter case, there's a secondary issue: should the base URI be a
> resource or a literal?
>
> The second issue is how you give a relative path (ie, within the ZIP) to
> a local instantiation of an input document. Do you use a file: uri with
> a relative (or absolute?) path? Or just a literal?
>
>
> Weighing against this is the need to keep the manifest file simple and
> regular (so it can be parsed only using a simple XML parser, if
> required - to bootstrap parser tests).
>
>
> jan
>
> PS. My feelings are: use anonymous nodes to represent an input document,
> and literals to give addresses of instantiations (base URI and local
> copy) - but that might be a little contentious.
>
>
>
> --
> jan grant, ILRT, University of Bristol. http://www.ilrt.bris.ac.uk/
> Tel +44(0)117 9287088 Fax +44 (0)117 9287112 RFC822 jan.grant@bris.ac.uk
> Hang on, wasn't he holding a wooden parrot? No! It was a porcelain owl.
>
>
>
>

-- 
Arthur Barstow
W3C [MIT]
mailto:barstow@w3.org
http://www.w3.org/People/Barstow/
MIT: +1-617-253-7697
Received on Thursday, 27 September 2001 05:17:59 EDT

This archive was generated by hypermail pre-2.1.9 : Wednesday, 3 September 2003 09:39:50 EDT