You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@jena.apache.org by Arthur Vaïsse-Lesteven <ar...@yahoo.fr> on 2013/09/27 15:43:35 UTC
Trubble with config.ttl that impact queries' semantics
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 "liferay_portal@liferay.sys"^^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 "liferay_portal@liferay.sys"^^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 "liferay_portal@liferay.sys"^^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.
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 | "liferay_portal@liferay.sys"^^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
Re: Trubble with config.ttl that impact queries' semantics
Posted by Andy Seaborne <an...@apache.org>.
Maybe this will help:
com.hp.hpl.jena.sparql.core.DynamicDatasets
which is what TDB uses.
Andy
On 30/09/13 14:35, Arthur Vaïsse-Lesteven wrote:
>
>> Have you considered using GRAPH in the query? That is the better way to
>> access a specific graph. GRAPH accesses the dataset's graphs, while FROM
>> describes the dataset.
>
> Yes I had, but here I have no choice considering my goal. I build a SPARQL proxy based on the work of Costabello and Gandon ( INRIA sophia antipolis : http://wimmics.inria.fr/projects/shi3ld/ )
>
>
> This proxy rewrite on the fly SPARQL queries and and FROM <graph> clauses to restrict the range of the query. Realising that FROM interpretation can change depending the endpoint implementation is very annoying. It doesn't appear explicitly in the standard, but I have to live with it.
>
> I was just in integration trouble as the way Fuseki was start totally impacted the core functionalities of the security layer.
>
> Arthur VAÏSSE-LESTEVEN
>
>
> ________________________________
> De : Andy Seaborne <an...@apache.org>
> À : users@jena.apache.org
> Envoyé le : Lundi 30 septembre 2013 15h22
> Objet : Re: Trubble with config.ttl that impact queries' semantics
>
>
> On 30/09/13 07:44, Arthur Vaïsse-Lesteven wrote:
>> 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 ?
>
> Yes.
>
>> Can we swap a non-TDB service to a TDB behaviour concerning the "from <graph uri>" ?
>
> Not in the current codebase. The behaviour of FROM to GET a URL
> remotely is a valid usecase. There could be another implementation of
> DatasetGraph that provided dynamic datasets. (I have unfinished code in
> my personal github to do this.)
>
>> If yes, I supposed we have to override some class to change this behaviour.
>
> Have you considered using GRAPH in the query? That is the better way to
> access a specific graph. GRAPH accesses the dataset's graphs, while FROM
> describes the dataset.
>
> 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 "liferay_portal@liferay.sys"^^xsd:String.
> ?user uso:password "liferay_portal"^^xsd:String.
> ?user ?p ?o.
> OPTIONAL { ?o uso:name ?n }
> }
> }
>
>
>
>>
>> Arthur VAÏSSE-LESTEVEN
Re: Trubble with config.ttl that impact queries' semantics
Posted by Arthur Vaïsse-Lesteven <ar...@yahoo.fr>.
>Have you considered using GRAPH in the query? That is the better way to
>access a specific graph. GRAPH accesses the dataset's graphs, while FROM
>describes the dataset.
Yes I had, but here I have no choice considering my goal. I build a SPARQL proxy based on the work of Costabello and Gandon ( INRIA sophia antipolis : http://wimmics.inria.fr/projects/shi3ld/ )
This proxy rewrite on the fly SPARQL queries and and FROM <graph> clauses to restrict the range of the query. Realising that FROM interpretation can change depending the endpoint implementation is very annoying. It doesn't appear explicitly in the standard, but I have to live with it.
I was just in integration trouble as the way Fuseki was start totally impacted the core functionalities of the security layer.
Arthur VAÏSSE-LESTEVEN
________________________________
De : Andy Seaborne <an...@apache.org>
À : users@jena.apache.org
Envoyé le : Lundi 30 septembre 2013 15h22
Objet : Re: Trubble with config.ttl that impact queries' semantics
On 30/09/13 07:44, Arthur Vaïsse-Lesteven wrote:
> 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 ?
Yes.
> Can we swap a non-TDB service to a TDB behaviour concerning the "from <graph uri>" ?
Not in the current codebase. The behaviour of FROM to GET a URL
remotely is a valid usecase. There could be another implementation of
DatasetGraph that provided dynamic datasets. (I have unfinished code in
my personal github to do this.)
> If yes, I supposed we have to override some class to change this behaviour.
Have you considered using GRAPH in the query? That is the better way to
access a specific graph. GRAPH accesses the dataset's graphs, while FROM
describes the dataset.
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 "liferay_portal@liferay.sys"^^xsd:String.
?user uso:password "liferay_portal"^^xsd:String.
?user ?p ?o.
OPTIONAL { ?o uso:name ?n }
}
}
>
> Arthur VAÏSSE-LESTEVEN
Re: Trubble with config.ttl that impact queries' semantics
Posted by Andy Seaborne <an...@apache.org>.
On 30/09/13 07:44, Arthur Vaïsse-Lesteven wrote:
> 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 ?
Yes.
> Can we swap a non-TDB service to a TDB behaviour concerning the "from <graph uri>" ?
Not in the current codebase. The behaviour of FROM to GET a URL
remotely is a valid usecase. There could be another implementation of
DatasetGraph that provided dynamic datasets. (I have unfinished code in
my personal github to do this.)
> If yes, I supposed we have to override some class to change this behaviour.
Have you considered using GRAPH in the query? That is the better way to
access a specific graph. GRAPH accesses the dataset's graphs, while FROM
describes the dataset.
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 "liferay_portal@liferay.sys"^^xsd:String.
?user uso:password "liferay_portal"^^xsd:String.
?user ?p ?o.
OPTIONAL { ?o uso:name ?n }
}
}
>
> Arthur VAÏSSE-LESTEVEN
Re: Trubble with config.ttl that impact queries' semantics
Posted by Arthur Vaïsse-Lesteven <ar...@yahoo.fr>.
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 <an...@apache.org>
À : users@jena.apache.org
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 <an...@apache.org>
> À : users@jena.apache.org
> 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 "liferay_portal@liferay.sys"^^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 "liferay_portal@liferay.sys"^^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 "liferay_portal@liferay.sys"^^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 | "liferay_portal@liferay.sys"^^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
>>
Re: Trubble with config.ttl that impact queries' semantics
Posted by Andy Seaborne <an...@apache.org>.
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 <an...@apache.org>
> À : users@jena.apache.org
> 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 "liferay_portal@liferay.sys"^^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 "liferay_portal@liferay.sys"^^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 "liferay_portal@liferay.sys"^^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 | "liferay_portal@liferay.sys"^^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
>>
Re: Trubble with config.ttl that impact queries' semantics
Posted by Arthur Vaïsse-Lesteven <ar...@yahoo.fr>.
>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.
Arthur VAÏSSE-LESTEVEN.
________________________________
De : Andy Seaborne <an...@apache.org>
À : users@jena.apache.org
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 "liferay_portal@liferay.sys"^^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 "liferay_portal@liferay.sys"^^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 "liferay_portal@liferay.sys"^^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 | "liferay_portal@liferay.sys"^^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
>
Re: Trubble with config.ttl that impact queries' semantics
Posted by Andy Seaborne <an...@apache.org>.
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 "liferay_portal@liferay.sys"^^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 "liferay_portal@liferay.sys"^^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 "liferay_portal@liferay.sys"^^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 | "liferay_portal@liferay.sys"^^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
>