Hi again,
> What's in config.ttl? I made my tests with the default file "config.ttl" that defined 2 datasets, "ds" and "books". As "books" doesn't support SPARQL update I made my tests on "ds". Testing with the default "config-tdb.ttl" allow the 2 queries to work on the "TDB Service (RW)" dataset. Just to check if I correctly understood, If my query contains "FROM <http://example.com#MyGraph>" In case of TDB the service will check if any local graph match this URI. Others will send an HTTP get to http://example.com#MyGraph, and execute the query on the dataset built on the base of this result. That is correct ? Can we swap a non-TDB service to a TDB behaviour concerning the "from <graph uri>" ? If yes, I supposed we have to override some class to change this behaviour. Arthur VAÏSSE-LESTEVEN ________________________________ De : Andy Seaborne <[email protected]> À : [email protected] Envoyé le : Samedi 28 septembre 2013 11h59 Objet : Re: Trubble with config.ttl that impact queries' semantics On 28/09/13 10:54, Arthur Vaïsse-Lesteven wrote: > >> Not really. >> >> In the case of TDB only, FROM picks a graph out of the dataset. Other >> datasets are likely to attempt to read it from the web. > > I thought that was the role of the SPARQL SERVICE to get data from different > endpoint on the web. > > I'll make some tests. > > Thank you for your answer. FROM/FROM NAMED "describes the dataset" to be queried. That's how some engines can be taking the names from the local pool of graphs and others do a HTTP GET. The spec does not prescribe "describe" here (quite intentionally). SERVICE <url> executes a remote sub-query in the middle of execution. The URL is a service endpoint, not a graph. Andy > > Arthur VAÏSSE-LESTEVEN. > > > > ________________________________ > De : Andy Seaborne <[email protected]> > À : [email protected] > Envoyé le : Vendredi 27 septembre 2013 18h31 > Objet : Re: Trubble with config.ttl that impact queries' semantics > > > What's in config.ttl? > > On 27/09/13 14:43, Arthur Vaïsse-Lesteven wrote: >> Hi, >> >> I just found something I don't understand. >> >> Using the last Fuseki server ( 1.0.0 ) I push some triples with a SPARQL >> insert, for example : >> >> PREFIX uso: <http://weblab.ow2.org/SWAG_users_ontology#> >> PREFIX rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> >> PREFIX xsd: <http://www.w3.org/2001/XMLSchema#> >> >> INSERT DATA { >> GRAPH <http://swag_data.com/users_graph> { >> <http://swag_data.com/User/portal> rdf:type uso:User. >> <http://swag_data.com/User/portal> uso:password >>"liferay_portal"^^xsd:String. >> <http://swag_data.com/User/portal> uso:name >>"[email protected]"^^xsd:String. >> <http://swag_data.com/User/portal> uso:hasAccessRestrictionLvl >><http://cassidian/COPS/not_restricted>. >> <http://swag_data.com/User/portal> uso:memberOfGroup >><http://swag_data.com/portal_user_group>. >> <http://swag_data.com/portal_user_group> uso:name >>"Portal"^^xsd:String. >> }. >> } >> >> >> My problem is that depending the way I start the server, I got different >> results from 2 queries that was supposed to be equals. The queries are : >> >> prefix uso: <http://weblab.ow2.org/SWAG_users_ontology#> >> PREFIX xsd: <http://www.w3.org/2001/XMLSchema#> >> >> SELECT ?p ?o ?n >> FROM <http://swag_data.com/users_graph> >> WHERE { >> ?user uso:name "[email protected]"^^xsd:String. >> ?user uso:password "liferay_portal"^^xsd:String. >> ?user ?p ?o. >> OPTIONAL { ?o uso:name ?n } >> } >> >> and >> >> prefix uso: <http://weblab.ow2.org/SWAG_users_ontology#> >> PREFIX xsd: <http://www.w3.org/2001/XMLSchema#> >> >> SELECT ?p ?o ?n >> WHERE { >> graph <http://swag_data.com/users_graph> { >> ?user uso:name "[email protected]"^^xsd:String. >> ?user uso:password "liferay_portal"^^xsd:String. >> ?user ?p ?o. >> OPTIONAL { ?o uso:name ?n } >> } >> } >> >> If I correctly understand the SPARQL standards, this two queries are >> supposed to give the same result. > > Not really. > > In the case of TDB only, FROM picks a graph out of the dataset. Other > datasets are likely to attempt to read it from the web. > > > >> And that what's append when I execute the update and the queries on the the >> dataset "test" against a >> Fuseki started with the command : "fuseki-server --update --loc "../test" >> /test" >> >> When I execute the two queries against the dataset ds of a Fuseki started by >> this command :"fuseki-server --config="./config.ttl" >> The first one don't find any matching result and the second give me the >> result same expected, obtained by the two queries with the other server : >> >> ----------------------------------------------------------------------------------------------------------------------- >> | p | o >> | n | >> ======================================================================================================================= >> | uso:memberOfGroup | >> <http://swag_data.com/portal_user_group> | "Portal"^^xsd:String | >> | uso:hasAccessRestrictionLvl | >> <http://cassidian/COPS/not_restricted> | | >> | uso:name | >> "[email protected]"^^xsd:String | | >> | uso:password | >> "liferay_portal"^^xsd:String | | >> | <http://www.w3.org/1999/02/22-rdf-syntax-ns#type> | uso:User >> | | >> ----------------------------------------------------------------------------------------------------------------------- >> >> Is that due to the default union graph parameters ? Is that comportment >> fully standard compliant ? If yes, which point of the standard did I missed? >> Because I thought that this 2 queries are semantically the same and I was >> expecting the same results in all contexts. >> >> VAÏSSE-LESTEVEN Arthur >>
