- From: Yoshio FUKUSHIGE <fuku@w3.org>
- Date: Thu, 2 Jun 2005 19:46:44 +0900
- 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 UTC