W3C home > Mailing lists > Public > www-rdf-interest@w3.org > August 2003

Re: RDF(S) tests and semantics

From: Steve Harris <S.W.Harris@ecs.soton.ac.uk>
Date: Wed, 6 Aug 2003 10:59:57 +0100
To: Dave Reynolds <der@hplb.hpl.hp.com>
Cc: www-rdf-interest@w3.org
Message-ID: <20030806095957.GB28750@ecs.soton.ac.uk>

On Wed, Aug 06, 2003 at 10:15:29 +0100, Dave Reynolds wrote:
> Summary: I agree with your observations and have already fed something similar
> back to the WG in:
>   http://lists.w3.org/Archives/Public/www-rdf-comments/2003JulSep/0076.html

Thank you, that's helpful. I'm going to follow suit and deliberatly fail
the seq-representation 2+4 and whitespace-facet-3 tests.

On the upside I found a stupid bug in my implementation of RDFS3 :)
> My guess is that this arises because the tests are framed in terms of mutual
> entailment between two graphs rather than query results over a graph. The
> phrasing of the section you quote, "set of graphs .. to check .. between those
> graphs", seems to suggest that if you are testing entailment between two graphs
> you check *both* of them for container membership properties and run the
> relevant comprehension rule over the union of the results. Thus, arguably, the
> closure triples corresponding to both the premise and conclusions documents from
> test002 should be added, which would make the test correct.

What I am actually doing is interring both graphs and then checking that
they are equivalent (with a simple graph matcher).

The problem with this is that it doesn't show up the fact that we ignore
datataype information, as it is discarded from both graphs on reading. We
obviously fail the datatype entailment tests though.

I'm going to run the entailment tests using a query however, as it looks
like you cant always get an equivalent graph from premise+entailments and

I haven't started on the negative tests.
> However, software systems like Jena and 3store are RDF access and query APIs
> and, as such, already have direct ways of testing that a node is a literal. To
> take your example above, if the application developer is saying "is there a
> value for the <bar> property on <foo> which is also a Literal" then they can do
> so directly through the query APIs without the need to actually generate these
> closure bNodes and then retrieve them. In principle, it would be possible to
> build an "entailment test to query" translator which handled all this. In
> practice, I believe application developers start with the query anyway so all we
> need is to ensure that the relevant queries can be expressed and executed.

Right, so I dont think the proposed entailment rule addresses this issue
in any case (as the bNode is not associated with any give triple), it can
tell you that there are values for (<foo>, <bar>, ?) that are Literal,
but not which ones or thier concrete types.

I think that some more strenuuous tests aimed at software conformance
testing would be of benefit, presumably this would be closely related to
the query tests, but I'm not sure how they handle entailments.

Received on Wednesday, 6 August 2003 06:00:04 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 15:07:47 UTC