W3C home > Mailing lists > Public > public-rdf-dawg@w3.org > April to June 2004

RE: Objective 4.6 -- additional semantic information

From: Rob Shearer <Rob.Shearer@networkinference.com>
Date: Wed, 9 Jun 2004 08:47:28 -0700
Message-ID: <CFE388CECDDB1E43AB1F60136BEB49730280D6@rome.ad.networkinference.com>
To: "Jim Hendler" <hendler@cs.umd.edu>, "Jos De_Roo" <jos.deroo@agfa.com>
Cc: "RDF Data Access Working Group" <public-rdf-dawg@w3.org>

> Maybe I didn't understand what 4.6 was about, I assumed it was 
> something like this:
> if I have
>    a rdfs:subClassOf b
>    b rdfs:subClassOf c
> then I was assuming that the requirments in UC&R would imply that if 
> I query for
>    a rdfs:subClassOf ?x
> then ?x would be bound to b
> however, if we include 4.6, then we would be expected to return
>    ?x = b and ?x = c

I think it would be wrong to require implementations to return both 'b'
and 'c', because that would be *requiring* implementations to process
But I think it would also be wrong to forbid returning 'b' and 'c' from
queries against some larger knowledgebase. In this case the problem is
hard to produce, since most (every?) extra piece of RDFS can simply be
encoded as a whole bunch of extra triples in an RDF graph, but that's
not the case for all extra sources of knowledge.

For example, if the standard were to define disjunction such that the
predicate "(a R b) OR (c S d)" is defined to return 'true' if and only
if "a R b" returns 'true' or "c S d" returns 'true', then it's
impossible for a standards-compliant processor to return sensible
results in a situation where the disjunction is a logical consequence of
the knowledgebase, yet neither of the individual triples is.

If, however, the standard were written in terms of the semantics of the
graphs which match such a disjunctive predicate, then more advanced
processors could legally return results that actually represented all
the knowledge at their disposal.

This is the difference between specifying the semantics of the query
language and specifying its implementation.
Received on Wednesday, 9 June 2004 11:57:46 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 15:00:44 UTC