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

Test cases: source of a triple

From: Seaborne, Andy <andy.seaborne@hp.com>
Date: Thu, 26 Aug 2004 09:47:46 +0100
Message-ID: <E864E95CB35C1C46B72FEA0626A2E80803E3C027@0-mail-br1.hpl.hp.com>
To: RDF Data Access Working Group <public-rdf-dawg@w3.org>

These are example of things that would like to see clearly decided: its not
that here are no answers or approaches here but I think these are some of
the decision points.


== Test case 1 : union case:

  :r :p :v .

  :r :p :v .

This has one result:
    SELECT * WHERE { ?x ?y ?z }

But this has two if source information is retained, and one if it is not:
    SELECT * WHERE { ?x ?y ?z ?src }

I find that strange.  It is explicable but, in RDF terms, there is only one
statement.  There are two statings.  Are we querying statements or statings?

(Syntax is quads-like [*].)

== Test case 2: inference

  :x rdf:type :C1 .
  :C1 rdfs:subClassOf :C2 .

    SELECT * WHERE { ?x rdf:type :C2 }

?x = :x
?src = <a.rdf> maybe.

Now suppose:
  :x rdf:type :C1 .
  :x rdf:type :C2 .
  :C1 rdfs:subClassOf :C2 .

Now ?src = <a.rdf>

but a1.rdf and a2.rdf have the RDFS-same information.
Should it be the same whether :x rdf:type :C2 .is explicit or inferred?  
(Forward rules systems where rules are run at ingestion time would not be
able to differentiate).

== Test case 3: Inference by multiple routes:

Now if:

  :x rdf:type :C1 .

  :C1 rdfs:subClassOf :C2 .

With a.rdf + b.rdf: get ?x = :x, but what is ?src

And if:

  :x rdf:type :C1 .
  :C1 rdfs:subClassOf :C2 .

  :C1 rdfs:subClassOf :C2 .

the RDF merge is the same but there are two ways to get the :x rdf:type :C2.
and there is only one query solution.

Seems to be getting a step on the way to proofs here.


[*] The modified syntax does not cover SOURCE precisely because it is
unclear if it applies to a triple or a graph pattern.  This syntax is quads
so is triple-based - its not very clear.  Maty should have an explit
"SRC(?x)" and a plain triple.
Received on Thursday, 26 August 2004 08:48:04 UTC

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