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

Re: test cases for fromUnionQuery, please

From: Yoshio FUKUSHIGE <fuku@w3.org>
Date: Thu, 2 Jun 2005 19:46:44 +0900
Message-ID: <004a01c56760$5e7f2780$f1e41b85@steelball>
To: <kendall@monkeyfist.com>
Cc: "DAWG Mailing List" <public-rdf-dawg@w3.org>

Hi, Kendall

> I'm saying that there are two broad kinds of use cases:
>
>   1. those where the service provider is willing to allow the query
>   requester to completely determine the RDF dataset
>
>   2. those where the service provider isn't willing to allow the query
>   requester to completely determine the RDF dataset
>
> Or so it seems to me. And if I understand your proposal correctly, it does
> not allow deployments of type (2), because it doesn't allow a service
> provider to add triples to a background or default graph.

Correct, but only when the requester doesn't want the provider to do so.

Let me say it again, a requester may allow the provider to do so
by writing (or adding)
FROM <http://a-service-providers-end-point-uri/>

>> Perhaps your SPARQL service can just reject queries that includes 
>> unwanted
>> FROM instructions.
>
> Well, sure, of course  it can do that. But that's not the problem. I 
> oppose
> any design that does not allow a service provider to add triples to the
> default (or "background") graph.

How about rejecting all queries wihtout FROM <http://your-end-point-uri/>?
i.e. by saying, "If you want to ask me, you should trust my nice dataset"

It's totally a service design and upto a service provider.
(and it should be written in the service advertisement...)

>> It's a protocol issue. Say, for example, "Sorry, we don't have (or trust)
>> data you mentioned".
>
> Well, there's no point deploying a service that has to refuse most 
> queries,
> instead of being able to answer them against the RDF dataset it prefers.

Again, a requester who doesn't want to be rejected can add
the FROM <http://service-point-url/ > clause, which should be advertised.

It's upto the requester, the matter of preference. Being conservative in
what/whom to believe and learn less, or being open and learn more.

>> 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.
>
> I think this is just an issue we haven't talked about a lot. I can see yr
> point of view, but I think it's unneccessarily restrictive.

Mmm, I don't think it restrictive, but rather giving more freedom.

# In a technology and society point of view, I don't want to be given
# controlled / over-dressed information in blind

>> Does this help my idea to get better understood?
>
> Yes, I think I understand it better, but I don't think I'm closer to
> supporting it. :>

Of course, this distinction is important : )
But I believe we can live together with my proposal.

Best,
Yoshio
fukushige.yoshio@jp.panasonic.com
fuku@w3.org
Received on Thursday, 2 June 2005 10:46:47 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 16:15:23 GMT