Re: ask and you shall be redirected

On 11/24/11 12:43 PM, Peter Williams wrote:
> The current spec counsels implementors to use
>
> PREFIX : <http://www.w3.org/ns/auth/cert#>
> ASK {
> <https://bob.example/webid#public> :key [
>       :modulus 
> "cb24ed85d64d794b69c701c186acc059501e856000f661c93204d8380e07191c5c8b368d2ac32a428acb970398664368dc2a867320220f755e99ca2eecdae62e8d15fb58e1b76ae59cb7ace8838394d59e7250b449176e51a494951a1c366c6217d8768d682dde78dd4d55e613f8839cf275d4c8403743e7862601f3c49a6366e12bb8f498262c3c77de19bce40b32f89ae62c3780f5b6275be337e2b3153ae2ba72a9975ae71ab724649497066b660fcf774b7543d980952d2e8586200eda4158b014e75465d91ecf93efc7ac170c11fc7246fc6ded79c37780000ac4e079f671fd4f207ad770809e0e2d7b0ef5493befe73544d8e1be3dddb52455c61391a1"^^xsd:hexBinary;
>       :exponent 65537;
>
>
> I need help from folks who understand query semantics (and ideally 
> secure query semantics).
>
> I could pull the graph from the webid in the cert, and follow 
> redirects., bob.example is redirected to bob.xxx. Ive no idea if the 
> identity of the graph in the local repository is titled with the 
> webid, or the fourth redirect the webget library I've used just 
> followed. When  I issue the above query, with the webid from the 
> cert(bob.example)  against the local triple store (sourced to 
> bob.xxx), will it match my graph? Assume my graph has no cert.identity 
> (deprecated) and no foaf.name property.
>
> Now, as I recall there was a variant, in which there was the likes of 
> SELECT FROM <uri> (and presumably there is an ASK FROM <uri>.)
>
> Does it make any difference whether I webget a graph (following 
> redirects) or use FROM?

Depends on the SPARQL engine, bottom line.

You key (and valid) concern is this: how to trigger or not trigger a 
"crawl" re. SPARQL ASK. Personally, SPARQL specificity in the spec is 
bad, that's an implementation detail re. Linked Data in general. The 
spec should simply focus on the fact that a "match" has to exist, 
bearing in mind the unpredictable expanse of any true Linked Data graph.

The item above is extremely important for implementers of WebID. We 
cannot mandate that they build SPARQL engines or even support SPARQL.

For someone in possession of extremely sophisticated SPARQL technology, 
I still wouldn't encourage any Linked Data oriented spec that pushed RDF 
and SPARQL specificity. Doing so ultimately introduces adoption inertia 
and conceptual confusion via conflation of core concepts and 
implementation details.

>
> Can I assume that the handling of redirects and any fixups in the 
> query as presented is specified in the query language design, when one 
> uses the FROM option?

FROM in SPARQL enables scoping queries to Named Partitions (using Graph 
IRIs) in a SPARQL server. It doesn't necessarily mandate a de-reference 
act if the referent (in this case a resource that consists of EAV/SPO 
triples) of a Named Graph IRI isn't local or returns no data. This is 
why in our implementation we use pragmas as a mechanism for instructing 
the Virtuoso engine to behave in a specific way.
>
> Which is more "appropirate" for the state of the web, today?

In our opinion, FROM should be a mechanism for "on the fly" bulk 
population of a SPARQL engine. In addition, variables in the SPARQL 
query pattern should also be mechanisms of more constrained de-reference 
actions (follow-your-nose pattern).

At the current time, SPARQL-FED does provide some improvement on 
direction re. federating queries, but there's much more needed in this 
realm.

Again, this is why SPARQL shouldn't be covertly mandated for WebID 
implementers. It has to be an option. What should be mandatory is 
walking a Linked Data graph en route to finding a match. Of course, the 
walk has to be within configurable reason :-)

>
>
>
>
>
>


-- 

Regards,

Kingsley Idehen	
Founder&  CEO
OpenLink Software
Company Web: http://www.openlinksw.com
Personal Weblog: http://www.openlinksw.com/blog/~kidehen
Twitter/Identi.ca handle: @kidehen
Google+ Profile: https://plus.google.com/112399767740508618350/about
LinkedIn Profile: http://www.linkedin.com/in/kidehen