Re: SPARQL Protocol for RDF

>
> form of description is mandated for DESCRIBE (and IMO shouldn't
> be) there should at least be *some* form of default form of
> description recommended -- so that implementers of SPARQL processors
> would adopt some consistent form of response unless they had
> strong reasons to do otherwise, but it seems such a proposal
> is not sufficiently valued by enough members of the WG.

Hasnt someone suggested a way to point at some URI for the definition of 
either the requested description or the one that's being provided.?

> CONSTRUCT
> {
>    ?s1 ?p1 ?o1 .
>    ?o1 ?p2 ?o2 .
>    ?r1 rdf:subject   ?s1 .
>    ?r1 rdf:predicate ?p1 .
>      ?r2 ?r2p ?r2o .
>    }
> }
>
> I guess this can be seen as a "poor man's CBD for SPARQL".

make that desperate man's ;-) you cant do it fully given there are no 
recursive queries.

> Of course, one could easily autogenerate a pretty exhaustive
> version that would cover essentially all practical cases.

:-) maybe...
 
anyway,  of course if there was syntactic support for reification your 
example be would much smaller and clearer , but syntactic support (which 
doesnt appear to be a major implementation burden, isnt it a regex 
substitution?) was removed.

While i understand CBD , Minimum Self Contained graphs are probably 
"strange" concepts, what made me sad is giving up the idea of using 
SPARQL also in other projects such as RDF Textual encoding  [1].  since 
there is no support for lists.
While i do understand why it seems difficult to implement certain 
features efficiently, i dont get it why the standard could list them 
anyway.. and people would just know that if they were to use them they'd 
pay a high computational price. Better that having to write a lot of 
java code..

In a partly unrelated matter, does anyone know how can one cope in 
sparql with contexts being more than 1?
Say one uses NG to indicate who is the author. Ok..  then after some 
time one wants to distinguish also  between the "red" triples and "blue" 
ones, or from other facets such as the original site where they were 
posted et. or whatever. 
Should one exponentially multiply the number of named graphs (creating 
new  graphs like fromGiovanni_red   fromGiovanni_blue ) 
(facetvalues)^(number of facets) , make a number of graphs equal to the 
triples (in case of fuzzy trust values for example) or simply duplicate 
triples once per aspect. (the same triple should appear in the giovanni 
graph AND in the red graph and of course i should remember where to 
delete it from the red graph when giovanni revokes it as well).
is there a best practices suggestion for this already?

>
> I do expect/hope to see knowledge portals supporting
> both SPARQL query interfaces as well as URIQA query
> interfaces, and agents can then benefit the most from
> both, either asking /sparql?query=... or /uriqa?uri=...
>
without a way to specify the description kind i guess it will be hard 
that URIQA will be practically supported. Which is a pity.. since 
serving CBDs (or RDFN, MSGs) can be proven to be scalable similar to 
today's web,  each request  having a computational complexity at worse 
proportional to the number of blank nodes. However, it can be fully 
cached ( with a size just a factor of the original graph) and efficient 
caching update algorithms are possible (you can have a reverse index on 
the URIs it touches so when someone inserts a statement the cache can be 
recalculated). On the contrary letting people execute arbitrary sparql 
at your server seems to me hardly sustainable in the open once the SW 
moves from good faith aggregation hackers to the real world...no?

Giovanni

[1]  Early version 
http://giovanni.ea.unian.it/semanticweb/submissions/ELPUB2005/rdftef.pdf

Received on Thursday, 2 June 2005 22:00:05 UTC