Re: SPARQL Protocol for RDF

Just a head's up. After today, I'm on vacation until the end of June,
so if I don't participate further in this thread, that's why...

Cheers,

Patrick


On Jun 3, 2005, at 00:59, ext Giovanni Tummarello wrote:

>
>>
>> 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 Friday, 3 June 2005 04:45:40 UTC