Re: test cases for fromUnionQuery, please

Hi,

Kendall:
> Re: (3)
>
>> Other things that become illegal in this design are answers
>> that come from beyond the graphs given in the query. I doubt
>> that can be expressed in our current test harness, but I suppose
>> we could figure out some way to do it.
>
> I'd like to clarify (well: change) my straw poll response re: (3): I 
> believe
> my org would object formally to it.
>
> Here's why: it makes it impossible (or: very hard) to satisfy one broad 
> set
> of use cases (speaking loosely) for SPARQL, namely, to publish a set of
> graphs describing some particular view of the world. Suppose that I'm a
> small web publisher, and I want to allow RDF queries over my article
> metadata, but I only want to answer queries against RDF datasets which
> include some set of triples that reflect some claims I want to make.
>
> So, for example, let's say I'm a publisher, and I always want these 
> triples
> to be in any RDF dataset for which I'm willing to answer a query:
>
> tag:hackingcongress.info,2004-10-05:/U.S.+Presidency/Bush,George+W,
>         rdf:type, http://www.icc-cpi.int/RDF/#war-criminal.
>
> tag:monkeyfist.com,2005-05-31:/US-War-on-Iraq,
>         rdf:type, http://www.icj-cij.org/RDF/#illegal-aggression

# I would furhter want US:GBush rdf:type animal:chimp :-)

I'm sorry, Kendall, but I don't see your point.

Are you saying that your SPARQL service doesn't want to
answer queries using other data set thatn those which belong to you (or you 
trust)?

Then the problem is how to reject unwanted FROM (NAMED) instructions,
and it is independent from my design, I mean it applies to all the designs.

Perhaps your SPARQL service can just reject queries that includes unwanted 
FROM instructions.

It's a protocol issue. Say, for example, "Sorry, we don't have (or trust) 
data you mentioned".

> Yoshio's design has the implication that SPARQL is only *really* useful 
> for
> "pure" query answering services; that is, a compliant SPARQL service can
> only answer queries against RDF datasets that are wholly specified by the
> agent asking the query. That's certainly one use of SPARQL, and one I 
> might
> be interested in, say, as an entrepreneur.
>
> But as a publisher, with a point of view, I don't believe that it works 
> for
> me, because I cannot supplement or include in an RDF dataset any arbitrary
> triples I'd like to include.

Well, it seems to be a  variant of  "a battle between two gods of 
literature"
(cf. Tim's key note at WWW2005 )[1] ..

Think, on the contray, I'm sure you don't want to be answered with database
including such triples as

 tag:hackingcongress.info,2004-10-05:/U.S.+Presidency/Bush,George+W,
         rdf:type, http://www.icc-cpi.int/RDF/#liberator.

 tag:monkeyfist.com,2005-05-31:/US-War-on-Iraq,
         rdf:type, http://www.icj-cij.org/RDF/#greatLiberation.

What I want to achieve is "to preserve (for the query issuer) the way to
exclude use of data unknown (or untrustworthy) to him/her", and it doesn't 
mean
the query issuer should always specify the set of the URIs of the concrete 
data.

For example, if you want to ask a SPARQL service, endpoint URI being, say, 
http://sparql.example.org/,
and you don't care what data it  uses (you trust the service), you can 
simply write

---
FROM <http://saprql.example.org/> # meant to have single <>'s (my mailer 
looks to have put one pair away)
SELECT ...
WHERE {...}
---

Does this help my idea to get better understood?

[1] http://www.w3.org/2005/Talks/0511-keynote-tbl/#[3]

Cheers,
Yoshio
fukushige.yoshio@jp.panasonic.com
fuku@w3.org

Received on Wednesday, 1 June 2005 10:19:08 UTC