- From: Patrick Stickler <patrick.stickler@nokia.com>
- Date: Fri, 3 Jun 2005 07:44:42 +0300
- To: "ext Giovanni Tummarello" <giovanni@wup.it>
- Cc: public-rdf-dawg-comments@w3.org, "<semantic-web@w3.org>" <semantic-web@w3.org>
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:36 UTC