how to address the Graph Store's default graph in a SPARQL QUERY

classic Classic list List threaded Threaded
18 messages Options
Reply | Threaded
Open this post in threaded view
|

how to address the Graph Store's default graph in a SPARQL QUERY

Armando Stellato

Dear all,

 

The issue is: through the Sesame2 Repository API, I’m able to retrieve statements from the null context only. I can’t do this through SPARQL (not simply at least).

 

I looked for previous posts about this before sending this email:

 

So far, most of the stuff is here:

[1] http://www.openrdf.org/forum/mvnforum/viewthread?thread=1518

[2] http://www.openrdf.org/issues/browse/SES-848

[3] http://www.openrdf.org/issues/browse/SES-849

[4] https://openrdf.atlassian.net/browse/SES-850

 

I read about your solution, with sesame:nil, and the proposal you made for standardizing this in SPARQL, with FROM DEFAULT (rejected). Thus, I thought it was an idiosyncrasy between the notion of null context in Sesame2 which maybe is not so close to the notion of default graph in SPARQL.

I thus decided to forget about technology, and see at least how the problem is addressed in SPARQL.

 

The SPARQL specifications are rather weird in this:

 

1) SPARQL 1.1 QUERY specifications define an RDF Dataset's default graph as a defineable graph (scoped to the query) which is either:

a) the "RDF Merge" of all named graphs, IFF no FROM/FROM NAMED clause is given

b) the dynamic "RDF Merge" of the sole graphs specified in one or more FROM clause

 

2) SPARQL 1.1 UPDATE specifications define a "Graph Store" 's default graph as the unique "UNNAMED GRAPH" in the store. If no graph is specified in an update, the information is stored in the unnamed graph. A Graph Store's default graph seems to be in a 1-1 relationship with the Sesame's null context

 

So, issue is: how to indicate the "Graph Store"'s default graph in a SPARQL QUERY? There seems to be no link among them! SPARQL UPDATE seems to define something (Graph Store’s default graph) very close to the null context of Sesame2, while SPARQL QUERY has its own definition of default graph (RDF Dataset’s one), but no way to explicitly access the triples in the Graph Store’s default graph.

 

Am I missing anything?

 

Cheers,

 

Armando

 

P.S: btw, I tried to use the sesame:nil graph, but no results. I’m using sesame 2.6.8, which was supposed to include it, unless it has been trashed later. Is the namespace the usual one? http://www.openrdf.org/schema/sesame#

 

P.P.S: I know we can obtain this through proper use of !BOUND, MINUS, NOT EXISTS etc… just I’m puzzled by the fact that there is no shorter and more explicit solution (and possibly defined at SPARQL level, not using any store’s specific extension). This hinders simplicity of code, other than performance…

 

--------------------------------------------------

 

Ing. Armando Stellato, PhD

AI Research Group,

Dept. of Enterprise Engineering

University of Roma, Tor Vergata

Via del Politecnico 1 00133 ROMA (ITALY)

tel: +39 06 7259 7330 (office, room A1-14);

     +39 06 7259 7332 (lab)

fax: +39 06 7259 7460

e_mail: [hidden email]

 

--------------------------------------------------

 


------------------------------------------------------------------------------
Android is increasing in popularity, but the open development platform that
developers love is also attractive to malware creators. Download this white
paper to learn more about secure code signing practices that can help keep
Android apps secure.
http://pubads.g.doubleclick.net/gampad/clk?id=65839951&iu=/4140/ostg.clktrk
_______________________________________________
Sesame-general mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/sesame-general
Reply | Threaded
Open this post in threaded view
|

Re: how to address the Graph Store's default graph in a SPARQL QUERY

David Booth-2
Hi Armando,

I'm not entirely sure that I understand your question, but SPARQL 1.1
Query has notions of:

   - the *default* graph, which will either consist of the merge of
named graphs that are specified using the FROM syntax; or it will
consist of somewhat unspecified content that *may* (by default) consist
of the merge of all of the named graphs in the store (but IIRC this is
not required by the standard).
http://www.w3.org/TR/sparql11-query/#unnamedGraph

   - the *active* graph, which is the graph against which a particular
triple pattern will be matched, and may be either the default graph or a
specifi named graph (if the GRAPH keyword is used).
http://www.w3.org/TR/sparql11-query/#rdfDataset

Does that help?

David

On 10/31/2013 12:31 PM, Armando Stellato wrote:

> Dear all,
>
> The issue is: through the Sesame2 Repository API, I’m able to retrieve
> statements from the null context only. I can’t do this through SPARQL
> (not simply at least).
>
> I looked for previous posts about this before sending this email:
>
> So far, most of the stuff is here:
>
> [1] http://www.openrdf.org/forum/mvnforum/viewthread?thread=1518
>
> [2] http://www.openrdf.org/issues/browse/SES-848
>
> [3] http://www.openrdf.org/issues/browse/SES-849
>
> [4] https://openrdf.atlassian.net/browse/SES-850
>
> I read about your solution, with sesame:nil, and the proposal you made
> for standardizing this in SPARQL, with FROM DEFAULT(rejected). Thus, I
> thought it was an idiosyncrasy between the notion of null context in
> Sesame2 which maybe is not so close to the notion of default graph in
> SPARQL.
>
> I thus decided to forget about technology, and see at least how the
> problem is addressed in SPARQL.
>
> The SPARQL specifications are rather weird in this:
>
> 1) SPARQL 1.1 QUERY specifications define an RDF Dataset's /default
> graph/ as a defineable graph (scoped to the query) which is either:
>
> a) the "RDF Merge" of all named graphs, IFF no FROM/FROM NAMED clause is
> given
>
> b) the dynamic "RDF Merge" of the sole graphs specified in one or more
> FROM clause
>
> 2) SPARQL 1.1 UPDATE specifications define a "Graph Store" 's /default
> graph/ as the unique "UNNAMED GRAPH" in the store. If no graph is
> specified in an update, the information is stored in the unnamed graph.
> A Graph Store's default graph seems to be in a 1-1 relationship with the
> Sesame's null context
>
> So, issue is: how to indicate the "Graph Store"'s default graph in a
> SPARQL QUERY? There seems to be no link among them! SPARQL UPDATE seems
> to define something (Graph Store’s default graph) very close to the null
> context of Sesame2, while SPARQL QUERY has its own definition of default
> graph (RDF Dataset’s one), but no way to explicitly access the triples
> in the Graph Store’s default graph.
>
> Am I missing anything?
>
> Cheers,
>
> Armando
>
> P.S: btw, I tried to use the sesame:nil graph, but no results. I’m using
> sesame 2.6.8, which was supposed to include it, unless it has been
> trashed later. Is the namespace the usual one?
> http://www.openrdf.org/schema/sesame#
>
> P.P.S: I know we can obtain this through proper use of !BOUND, MINUS,
> NOT EXISTS etc… just I’m puzzled by the fact that there is no shorter
> and more explicit solution (and possibly defined at SPARQL level, not
> using any store’s specific extension). This hinders simplicity of code,
> other than performance…
>
> --------------------------------------------------
>
> Ing. Armando Stellato, PhD
>
> AI Research Group,
>
> Dept. of Enterprise Engineering
>
> University of Roma, Tor Vergata
>
> Via del Politecnico 1 00133 ROMA (ITALY)
>
> tel: +39 06 7259 7330 (office, room A1-14);
>
>       +39 06 7259 7332 (lab)
>
> fax: +39 06 7259 7460
>
> e_mail: [hidden email] <mailto:[hidden email]>
>
> --------------------------------------------------
>
>
>
> ------------------------------------------------------------------------------
> Android is increasing in popularity, but the open development platform that
> developers love is also attractive to malware creators. Download this white
> paper to learn more about secure code signing practices that can help keep
> Android apps secure.
> http://pubads.g.doubleclick.net/gampad/clk?id=65839951&iu=/4140/ostg.clktrk
>
>
>
> _______________________________________________
> Sesame-general mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/sesame-general
>

------------------------------------------------------------------------------
Android is increasing in popularity, but the open development platform that
developers love is also attractive to malware creators. Download this white
paper to learn more about secure code signing practices that can help keep
Android apps secure.
http://pubads.g.doubleclick.net/gampad/clk?id=65839951&iu=/4140/ostg.clktrk
_______________________________________________
Sesame-general mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/sesame-general
Reply | Threaded
Open this post in threaded view
|

Re: how to address the Graph Store's default graph in a SPARQL QUERY

Barry Norton-2

I believe he wants to address only the null context via SPARQL. Which you can't (as I remember).

Barry



-----Original Message-----
From: David Booth [mailto:[hidden email]]
Sent: 31 October 2013 18:18
To: Sesame discussion list
Subject: Re: [Sesame] how to address the Graph Store's default graph in a SPARQL QUERY

Hi Armando,

I'm not entirely sure that I understand your question, but SPARQL 1.1 Query has notions of:

   - the *default* graph, which will either consist of the merge of named graphs that are specified using the FROM syntax; or it will consist of somewhat unspecified content that *may* (by default) consist of the merge of all of the named graphs in the store (but IIRC this is not required by the standard).
http://www.w3.org/TR/sparql11-query/#unnamedGraph

   - the *active* graph, which is the graph against which a particular triple pattern will be matched, and may be either the default graph or a specifi named graph (if the GRAPH keyword is used).
http://www.w3.org/TR/sparql11-query/#rdfDataset

Does that help?

David

On 10/31/2013 12:31 PM, Armando Stellato wrote:

> Dear all,
>
> The issue is: through the Sesame2 Repository API, I'm able to retrieve
> statements from the null context only. I can't do this through SPARQL
> (not simply at least).
>
> I looked for previous posts about this before sending this email:
>
> So far, most of the stuff is here:
>
> [1] http://www.openrdf.org/forum/mvnforum/viewthread?thread=1518
>
> [2] http://www.openrdf.org/issues/browse/SES-848
>
> [3] http://www.openrdf.org/issues/browse/SES-849
>
> [4] https://openrdf.atlassian.net/browse/SES-850
>
> I read about your solution, with sesame:nil, and the proposal you made
> for standardizing this in SPARQL, with FROM DEFAULT(rejected). Thus, I
> thought it was an idiosyncrasy between the notion of null context in
> Sesame2 which maybe is not so close to the notion of default graph in
> SPARQL.
>
> I thus decided to forget about technology, and see at least how the
> problem is addressed in SPARQL.
>
> The SPARQL specifications are rather weird in this:
>
> 1) SPARQL 1.1 QUERY specifications define an RDF Dataset's /default
> graph/ as a defineable graph (scoped to the query) which is either:
>
> a) the "RDF Merge" of all named graphs, IFF no FROM/FROM NAMED clause
> is given
>
> b) the dynamic "RDF Merge" of the sole graphs specified in one or more
> FROM clause
>
> 2) SPARQL 1.1 UPDATE specifications define a "Graph Store" 's /default
> graph/ as the unique "UNNAMED GRAPH" in the store. If no graph is
> specified in an update, the information is stored in the unnamed graph.
> A Graph Store's default graph seems to be in a 1-1 relationship with
> the Sesame's null context
>
> So, issue is: how to indicate the "Graph Store"'s default graph in a
> SPARQL QUERY? There seems to be no link among them! SPARQL UPDATE
> seems to define something (Graph Store's default graph) very close to
> the null context of Sesame2, while SPARQL QUERY has its own definition
> of default graph (RDF Dataset's one), but no way to explicitly access
> the triples in the Graph Store's default graph.
>
> Am I missing anything?
>
> Cheers,
>
> Armando
>
> P.S: btw, I tried to use the sesame:nil graph, but no results. I'm
> using sesame 2.6.8, which was supposed to include it, unless it has
> been trashed later. Is the namespace the usual one?
> http://www.openrdf.org/schema/sesame#
>
> P.P.S: I know we can obtain this through proper use of !BOUND, MINUS,
> NOT EXISTS etc... just I'm puzzled by the fact that there is no shorter
> and more explicit solution (and possibly defined at SPARQL level, not
> using any store's specific extension). This hinders simplicity of
> code, other than performance...
>
> --------------------------------------------------
>
> Ing. Armando Stellato, PhD
>
> AI Research Group,
>
> Dept. of Enterprise Engineering
>
> University of Roma, Tor Vergata
>
> Via del Politecnico 1 00133 ROMA (ITALY)
>
> tel: +39 06 7259 7330 (office, room A1-14);
>
>       +39 06 7259 7332 (lab)
>
> fax: +39 06 7259 7460
>
> e_mail: [hidden email] <mailto:[hidden email]>
>
> --------------------------------------------------
>
>
>
> ----------------------------------------------------------------------
> -------- Android is increasing in popularity, but the open development
> platform that developers love is also attractive to malware creators.
> Download this white paper to learn more about secure code signing
> practices that can help keep Android apps secure.
> http://pubads.g.doubleclick.net/gampad/clk?id=65839951&iu=/4140/ostg.c
> lktrk
>
>
>
> _______________________________________________
> Sesame-general mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/sesame-general
>

------------------------------------------------------------------------------
Android is increasing in popularity, but the open development platform that developers love is also attractive to malware creators. Download this white paper to learn more about secure code signing practices that can help keep Android apps secure.
http://pubads.g.doubleclick.net/gampad/clk?id=65839951&iu=/4140/ostg.clktrk
_______________________________________________
Sesame-general mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/sesame-general

------------------------------------------------------------------------------
Android is increasing in popularity, but the open development platform that
developers love is also attractive to malware creators. Download this white
paper to learn more about secure code signing practices that can help keep
Android apps secure.
http://pubads.g.doubleclick.net/gampad/clk?id=65839951&iu=/4140/ostg.clktrk
_______________________________________________
Sesame-general mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/sesame-general
Reply | Threaded
Open this post in threaded view
|

Re: how to address the Graph Store's default graph in a SPARQL QUERY

David Booth-2
Oh, I see.  Then AFAIK the best work-around is to not use the null
context.  Give it an explicit name instead.

David

On 10/31/2013 02:20 PM, Barry Norton wrote:

>
> I believe he wants to address only the null context via SPARQL. Which
> you can't (as I remember).
>
> Barry
>
>
>
> -----Original Message----- From: David Booth
> [mailto:[hidden email]] Sent: 31 October 2013 18:18 To: Sesame
> discussion list Subject: Re: [Sesame] how to address the Graph
> Store's default graph in a SPARQL QUERY
>
> Hi Armando,
>
> I'm not entirely sure that I understand your question, but SPARQL 1.1
> Query has notions of:
>
> - the *default* graph, which will either consist of the merge of
> named graphs that are specified using the FROM syntax; or it will
> consist of somewhat unspecified content that *may* (by default)
> consist of the merge of all of the named graphs in the store (but
> IIRC this is not required by the standard).
> http://www.w3.org/TR/sparql11-query/#unnamedGraph
>
> - the *active* graph, which is the graph against which a particular
> triple pattern will be matched, and may be either the default graph
> or a specifi named graph (if the GRAPH keyword is used).
> http://www.w3.org/TR/sparql11-query/#rdfDataset
>
> Does that help?
>
> David
>
> On 10/31/2013 12:31 PM, Armando Stellato wrote:
>> Dear all,
>>
>> The issue is: through the Sesame2 Repository API, I'm able to
>> retrieve statements from the null context only. I can't do this
>> through SPARQL (not simply at least).
>>
>> I looked for previous posts about this before sending this email:
>>
>> So far, most of the stuff is here:
>>
>> [1] http://www.openrdf.org/forum/mvnforum/viewthread?thread=1518
>>
>> [2] http://www.openrdf.org/issues/browse/SES-848
>>
>> [3] http://www.openrdf.org/issues/browse/SES-849
>>
>> [4] https://openrdf.atlassian.net/browse/SES-850
>>
>> I read about your solution, with sesame:nil, and the proposal you
>> made for standardizing this in SPARQL, with FROM DEFAULT(rejected).
>> Thus, I thought it was an idiosyncrasy between the notion of null
>> context in Sesame2 which maybe is not so close to the notion of
>> default graph in SPARQL.
>>
>> I thus decided to forget about technology, and see at least how
>> the problem is addressed in SPARQL.
>>
>> The SPARQL specifications are rather weird in this:
>>
>> 1) SPARQL 1.1 QUERY specifications define an RDF Dataset's
>> /default graph/ as a defineable graph (scoped to the query) which
>> is either:
>>
>> a) the "RDF Merge" of all named graphs, IFF no FROM/FROM NAMED
>> clause is given
>>
>> b) the dynamic "RDF Merge" of the sole graphs specified in one or
>> more FROM clause
>>
>> 2) SPARQL 1.1 UPDATE specifications define a "Graph Store" 's
>> /default graph/ as the unique "UNNAMED GRAPH" in the store. If no
>> graph is specified in an update, the information is stored in the
>> unnamed graph. A Graph Store's default graph seems to be in a 1-1
>> relationship with the Sesame's null context
>>
>> So, issue is: how to indicate the "Graph Store"'s default graph in
>> a SPARQL QUERY? There seems to be no link among them! SPARQL
>> UPDATE seems to define something (Graph Store's default graph) very
>> close to the null context of Sesame2, while SPARQL QUERY has its
>> own definition of default graph (RDF Dataset's one), but no way to
>> explicitly access the triples in the Graph Store's default graph.
>>
>> Am I missing anything?
>>
>> Cheers,
>>
>> Armando
>>
>> P.S: btw, I tried to use the sesame:nil graph, but no results. I'm
>> using sesame 2.6.8, which was supposed to include it, unless it
>> has been trashed later. Is the namespace the usual one?
>> http://www.openrdf.org/schema/sesame#
>>
>> P.P.S: I know we can obtain this through proper use of !BOUND,
>> MINUS, NOT EXISTS etc... just I'm puzzled by the fact that there is
>> no shorter and more explicit solution (and possibly defined at
>> SPARQL level, not using any store's specific extension). This
>> hinders simplicity of code, other than performance...
>>
>> --------------------------------------------------
>>
>> Ing. Armando Stellato, PhD
>>
>> AI Research Group,
>>
>> Dept. of Enterprise Engineering
>>
>> University of Roma, Tor Vergata
>>
>> Via del Politecnico 1 00133 ROMA (ITALY)
>>
>> tel: +39 06 7259 7330 (office, room A1-14);
>>
>> +39 06 7259 7332 (lab)
>>
>> fax: +39 06 7259 7460
>>
>> e_mail: [hidden email]
>> <mailto:[hidden email]>
>>
>> --------------------------------------------------
>>
>>
>>
>> ----------------------------------------------------------------------
>>
>>
-------- Android is increasing in popularity, but the open development
>> platform that developers love is also attractive to malware
>> creators. Download this white paper to learn more about secure code
>> signing practices that can help keep Android apps secure.
>> http://pubads.g.doubleclick.net/gampad/clk?id=65839951&iu=/4140/ostg.c
>>
>>
lktrk

>>
>>
>>
>> _______________________________________________ Sesame-general
>> mailing list [hidden email]
>> https://lists.sourceforge.net/lists/listinfo/sesame-general
>>
>
> ------------------------------------------------------------------------------
>
>
Android is increasing in popularity, but the open development platform
that developers love is also attractive to malware creators. Download
this white paper to learn more about secure code signing practices that
can help keep Android apps secure.
> http://pubads.g.doubleclick.net/gampad/clk?id=65839951&iu=/4140/ostg.clktrk
>
>
_______________________________________________
> Sesame-general mailing list [hidden email]
> https://lists.sourceforge.net/lists/listinfo/sesame-general
>
> ------------------------------------------------------------------------------
>
>
Android is increasing in popularity, but the open development platform that
> developers love is also attractive to malware creators. Download this
> white paper to learn more about secure code signing practices that
> can help keep Android apps secure.
> http://pubads.g.doubleclick.net/gampad/clk?id=65839951&iu=/4140/ostg.clktrk
>
>
_______________________________________________
> Sesame-general mailing list [hidden email]
> https://lists.sourceforge.net/lists/listinfo/sesame-general
>
>
>

------------------------------------------------------------------------------
Android is increasing in popularity, but the open development platform that
developers love is also attractive to malware creators. Download this white
paper to learn more about secure code signing practices that can help keep
Android apps secure.
http://pubads.g.doubleclick.net/gampad/clk?id=65839951&iu=/4140/ostg.clktrk
_______________________________________________
Sesame-general mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/sesame-general
Reply | Threaded
Open this post in threaded view
|

Re: how to address the Graph Store's default graph in a SPARQL QUERY

Barry Norton-2

I'm with you 100%.

One of my training mantras is: do not put explicit assertions in the [null context].

Barry


-----Original Message-----
From: David Booth [mailto:[hidden email]]
Sent: 31 October 2013 18:37
To: Sesame discussion list
Subject: Re: [Sesame] how to address the Graph Store's default graph in a SPARQL QUERY

Oh, I see.  Then AFAIK the best work-around is to not use the null context.  Give it an explicit name instead.

David

On 10/31/2013 02:20 PM, Barry Norton wrote:

>
> I believe he wants to address only the null context via SPARQL. Which
> you can't (as I remember).
>
> Barry
>
>
>
> -----Original Message----- From: David Booth [mailto:[hidden email]]
> Sent: 31 October 2013 18:18 To: Sesame discussion list Subject: Re:
> [Sesame] how to address the Graph Store's default graph in a SPARQL
> QUERY
>
> Hi Armando,
>
> I'm not entirely sure that I understand your question, but SPARQL 1.1
> Query has notions of:
>
> - the *default* graph, which will either consist of the merge of named
> graphs that are specified using the FROM syntax; or it will consist of
> somewhat unspecified content that *may* (by default) consist of the
> merge of all of the named graphs in the store (but IIRC this is not
> required by the standard).
> http://www.w3.org/TR/sparql11-query/#unnamedGraph
>
> - the *active* graph, which is the graph against which a particular
> triple pattern will be matched, and may be either the default graph or
> a specifi named graph (if the GRAPH keyword is used).
> http://www.w3.org/TR/sparql11-query/#rdfDataset
>
> Does that help?
>
> David
>
> On 10/31/2013 12:31 PM, Armando Stellato wrote:
>> Dear all,
>>
>> The issue is: through the Sesame2 Repository API, I'm able to
>> retrieve statements from the null context only. I can't do this
>> through SPARQL (not simply at least).
>>
>> I looked for previous posts about this before sending this email:
>>
>> So far, most of the stuff is here:
>>
>> [1] http://www.openrdf.org/forum/mvnforum/viewthread?thread=1518
>>
>> [2] http://www.openrdf.org/issues/browse/SES-848
>>
>> [3] http://www.openrdf.org/issues/browse/SES-849
>>
>> [4] https://openrdf.atlassian.net/browse/SES-850
>>
>> I read about your solution, with sesame:nil, and the proposal you
>> made for standardizing this in SPARQL, with FROM DEFAULT(rejected).
>> Thus, I thought it was an idiosyncrasy between the notion of null
>> context in Sesame2 which maybe is not so close to the notion of
>> default graph in SPARQL.
>>
>> I thus decided to forget about technology, and see at least how the
>> problem is addressed in SPARQL.
>>
>> The SPARQL specifications are rather weird in this:
>>
>> 1) SPARQL 1.1 QUERY specifications define an RDF Dataset's /default
>> graph/ as a defineable graph (scoped to the query) which is either:
>>
>> a) the "RDF Merge" of all named graphs, IFF no FROM/FROM NAMED clause
>> is given
>>
>> b) the dynamic "RDF Merge" of the sole graphs specified in one or
>> more FROM clause
>>
>> 2) SPARQL 1.1 UPDATE specifications define a "Graph Store" 's
>> /default graph/ as the unique "UNNAMED GRAPH" in the store. If no
>> graph is specified in an update, the information is stored in the
>> unnamed graph. A Graph Store's default graph seems to be in a 1-1
>> relationship with the Sesame's null context
>>
>> So, issue is: how to indicate the "Graph Store"'s default graph in a
>> SPARQL QUERY? There seems to be no link among them! SPARQL UPDATE
>> seems to define something (Graph Store's default graph) very close to
>> the null context of Sesame2, while SPARQL QUERY has its own
>> definition of default graph (RDF Dataset's one), but no way to
>> explicitly access the triples in the Graph Store's default graph.
>>
>> Am I missing anything?
>>
>> Cheers,
>>
>> Armando
>>
>> P.S: btw, I tried to use the sesame:nil graph, but no results. I'm
>> using sesame 2.6.8, which was supposed to include it, unless it has
>> been trashed later. Is the namespace the usual one?
>> http://www.openrdf.org/schema/sesame#
>>
>> P.P.S: I know we can obtain this through proper use of !BOUND, MINUS,
>> NOT EXISTS etc... just I'm puzzled by the fact that there is no
>> shorter and more explicit solution (and possibly defined at SPARQL
>> level, not using any store's specific extension). This hinders
>> simplicity of code, other than performance...
>>
>> --------------------------------------------------
>>
>> Ing. Armando Stellato, PhD
>>
>> AI Research Group,
>>
>> Dept. of Enterprise Engineering
>>
>> University of Roma, Tor Vergata
>>
>> Via del Politecnico 1 00133 ROMA (ITALY)
>>
>> tel: +39 06 7259 7330 (office, room A1-14);
>>
>> +39 06 7259 7332 (lab)
>>
>> fax: +39 06 7259 7460
>>
>> e_mail: [hidden email]
>> <mailto:[hidden email]>
>>
>> --------------------------------------------------
>>
>>
>>
>> ---------------------------------------------------------------------
>> -
>>
>>
-------- Android is increasing in popularity, but the open development
>> platform that developers love is also attractive to malware creators.
>> Download this white paper to learn more about secure code signing
>> practices that can help keep Android apps secure.
>> http://pubads.g.doubleclick.net/gampad/clk?id=65839951&iu=/4140/ostg.
>> c
>>
>>
lktrk

>>
>>
>>
>> _______________________________________________ Sesame-general
>> mailing list [hidden email]
>> https://lists.sourceforge.net/lists/listinfo/sesame-general
>>
>
> ----------------------------------------------------------------------
> --------
>
>
Android is increasing in popularity, but the open development platform that developers love is also attractive to malware creators. Download this white paper to learn more about secure code signing practices that can help keep Android apps secure.
> http://pubads.g.doubleclick.net/gampad/clk?id=65839951&iu=/4140/ostg.c
> lktrk
>
>
_______________________________________________
> Sesame-general mailing list [hidden email]
> https://lists.sourceforge.net/lists/listinfo/sesame-general
>
> ----------------------------------------------------------------------
> --------
>
>
Android is increasing in popularity, but the open development platform that
> developers love is also attractive to malware creators. Download this
> white paper to learn more about secure code signing practices that can
> help keep Android apps secure.
> http://pubads.g.doubleclick.net/gampad/clk?id=65839951&iu=/4140/ostg.c
> lktrk
>
>
_______________________________________________
> Sesame-general mailing list [hidden email]
> https://lists.sourceforge.net/lists/listinfo/sesame-general
>
>
>

------------------------------------------------------------------------------
Android is increasing in popularity, but the open development platform that developers love is also attractive to malware creators. Download this white paper to learn more about secure code signing practices that can help keep Android apps secure.
http://pubads.g.doubleclick.net/gampad/clk?id=65839951&iu=/4140/ostg.clktrk
_______________________________________________
Sesame-general mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/sesame-general

------------------------------------------------------------------------------
Android is increasing in popularity, but the open development platform that
developers love is also attractive to malware creators. Download this white
paper to learn more about secure code signing practices that can help keep
Android apps secure.
http://pubads.g.doubleclick.net/gampad/clk?id=65839951&iu=/4140/ostg.clktrk
_______________________________________________
Sesame-general mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/sesame-general
Reply | Threaded
Open this post in threaded view
|

Re: how to address the Graph Store's default graph in a SPARQL QUERY

Mike Grove-2
On Thu, Oct 31, 2013 at 2:40 PM, Barry Norton <[hidden email]> wrote:

I'm with you 100%.

One of my training mantras is: do not put explicit assertions in the [null context].

I'll respectively disagree on that point.  It's not clear that gives you any particular advantage.

wrt to the OP's question, "FROM DEFAULT" parses with the Sesame SPARQL parser just fine, and, afaict, works as expected.  It seems like a usable workaround to the fact that, by default, Sesame considers the active graph for query evaluation to be the union of the default context & all named graphs.

Cheers,

Mike
 

Barry


-----Original Message-----
From: David Booth [mailto:[hidden email]]
Sent: 31 October 2013 18:37
To: Sesame discussion list
Subject: Re: [Sesame] how to address the Graph Store's default graph in a SPARQL QUERY

Oh, I see.  Then AFAIK the best work-around is to not use the null context.  Give it an explicit name instead.

David

On 10/31/2013 02:20 PM, Barry Norton wrote:
>
> I believe he wants to address only the null context via SPARQL. Which
> you can't (as I remember).
>
> Barry
>
>
>
> -----Original Message----- From: David Booth [mailto:[hidden email]]
> Sent: 31 October 2013 18:18 To: Sesame discussion list Subject: Re:
> [Sesame] how to address the Graph Store's default graph in a SPARQL
> QUERY
>
> Hi Armando,
>
> I'm not entirely sure that I understand your question, but SPARQL 1.1
> Query has notions of:
>
> - the *default* graph, which will either consist of the merge of named
> graphs that are specified using the FROM syntax; or it will consist of
> somewhat unspecified content that *may* (by default) consist of the
> merge of all of the named graphs in the store (but IIRC this is not
> required by the standard).
> http://www.w3.org/TR/sparql11-query/#unnamedGraph
>
> - the *active* graph, which is the graph against which a particular
> triple pattern will be matched, and may be either the default graph or
> a specifi named graph (if the GRAPH keyword is used).
> http://www.w3.org/TR/sparql11-query/#rdfDataset
>
> Does that help?
>
> David
>
> On 10/31/2013 12:31 PM, Armando Stellato wrote:
>> Dear all,
>>
>> The issue is: through the Sesame2 Repository API, I'm able to
>> retrieve statements from the null context only. I can't do this
>> through SPARQL (not simply at least).
>>
>> I looked for previous posts about this before sending this email:
>>
>> So far, most of the stuff is here:
>>
>> [1] http://www.openrdf.org/forum/mvnforum/viewthread?thread=1518
>>
>> [2] http://www.openrdf.org/issues/browse/SES-848
>>
>> [3] http://www.openrdf.org/issues/browse/SES-849
>>
>> [4] https://openrdf.atlassian.net/browse/SES-850
>>
>> I read about your solution, with sesame:nil, and the proposal you
>> made for standardizing this in SPARQL, with FROM DEFAULT(rejected).
>> Thus, I thought it was an idiosyncrasy between the notion of null
>> context in Sesame2 which maybe is not so close to the notion of
>> default graph in SPARQL.
>>
>> I thus decided to forget about technology, and see at least how the
>> problem is addressed in SPARQL.
>>
>> The SPARQL specifications are rather weird in this:
>>
>> 1) SPARQL 1.1 QUERY specifications define an RDF Dataset's /default
>> graph/ as a defineable graph (scoped to the query) which is either:
>>
>> a) the "RDF Merge" of all named graphs, IFF no FROM/FROM NAMED clause
>> is given
>>
>> b) the dynamic "RDF Merge" of the sole graphs specified in one or
>> more FROM clause
>>
>> 2) SPARQL 1.1 UPDATE specifications define a "Graph Store" 's
>> /default graph/ as the unique "UNNAMED GRAPH" in the store. If no
>> graph is specified in an update, the information is stored in the
>> unnamed graph. A Graph Store's default graph seems to be in a 1-1
>> relationship with the Sesame's null context
>>
>> So, issue is: how to indicate the "Graph Store"'s default graph in a
>> SPARQL QUERY? There seems to be no link among them! SPARQL UPDATE
>> seems to define something (Graph Store's default graph) very close to
>> the null context of Sesame2, while SPARQL QUERY has its own
>> definition of default graph (RDF Dataset's one), but no way to
>> explicitly access the triples in the Graph Store's default graph.
>>
>> Am I missing anything?
>>
>> Cheers,
>>
>> Armando
>>
>> P.S: btw, I tried to use the sesame:nil graph, but no results. I'm
>> using sesame 2.6.8, which was supposed to include it, unless it has
>> been trashed later. Is the namespace the usual one?
>> http://www.openrdf.org/schema/sesame#
>>
>> P.P.S: I know we can obtain this through proper use of !BOUND, MINUS,
>> NOT EXISTS etc... just I'm puzzled by the fact that there is no
>> shorter and more explicit solution (and possibly defined at SPARQL
>> level, not using any store's specific extension). This hinders
>> simplicity of code, other than performance...
>>
>> --------------------------------------------------
>>
>> Ing. Armando Stellato, PhD
>>
>> AI Research Group,
>>
>> Dept. of Enterprise Engineering
>>
>> University of Roma, Tor Vergata
>>
>> Via del Politecnico 1 00133 ROMA (ITALY)
>>
>> tel: <a href="tel:%2B39%2006%207259%207330" value="+390672597330">+39 06 7259 7330 (office, room A1-14);
>>
>> <a href="tel:%2B39%2006%207259%207332" value="+390672597332">+39 06 7259 7332 (lab)
>>
>> fax: <a href="tel:%2B39%2006%207259%207460" value="+390672597460">+39 06 7259 7460
>>
>> e_mail: [hidden email]
>> <mailto:[hidden email]>
>>
>> --------------------------------------------------
>>
>>
>>
>> ---------------------------------------------------------------------
>> -
>>
>>
-------- Android is increasing in popularity, but the open development
>> platform that developers love is also attractive to malware creators.
>> Download this white paper to learn more about secure code signing
>> practices that can help keep Android apps secure.
>> http://pubads.g.doubleclick.net/gampad/clk?id=65839951&iu=/4140/ostg.
>> c
>>
>>
lktrk
>>
>>
>>
>> _______________________________________________ Sesame-general
>> mailing list [hidden email]
>> https://lists.sourceforge.net/lists/listinfo/sesame-general
>>
>
> ----------------------------------------------------------------------
> --------
>
>
Android is increasing in popularity, but the open development platform that developers love is also attractive to malware creators. Download this white paper to learn more about secure code signing practices that can help keep Android apps secure.
> http://pubads.g.doubleclick.net/gampad/clk?id=65839951&iu=/4140/ostg.c
> lktrk
>
>
_______________________________________________
> Sesame-general mailing list [hidden email]
> https://lists.sourceforge.net/lists/listinfo/sesame-general
>
> ----------------------------------------------------------------------
> --------
>
>
Android is increasing in popularity, but the open development platform that
> developers love is also attractive to malware creators. Download this
> white paper to learn more about secure code signing practices that can
> help keep Android apps secure.
> http://pubads.g.doubleclick.net/gampad/clk?id=65839951&iu=/4140/ostg.c
> lktrk
>
>
_______________________________________________
> Sesame-general mailing list [hidden email]
> https://lists.sourceforge.net/lists/listinfo/sesame-general
>
>
>

------------------------------------------------------------------------------
Android is increasing in popularity, but the open development platform that developers love is also attractive to malware creators. Download this white paper to learn more about secure code signing practices that can help keep Android apps secure.
http://pubads.g.doubleclick.net/gampad/clk?id=65839951&iu=/4140/ostg.clktrk
_______________________________________________
Sesame-general mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/sesame-general

------------------------------------------------------------------------------
Android is increasing in popularity, but the open development platform that
developers love is also attractive to malware creators. Download this white
paper to learn more about secure code signing practices that can help keep
Android apps secure.
http://pubads.g.doubleclick.net/gampad/clk?id=65839951&iu=/4140/ostg.clktrk
_______________________________________________
Sesame-general mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/sesame-general


------------------------------------------------------------------------------
Android is increasing in popularity, but the open development platform that
developers love is also attractive to malware creators. Download this white
paper to learn more about secure code signing practices that can help keep
Android apps secure.
http://pubads.g.doubleclick.net/gampad/clk?id=65839951&iu=/4140/ostg.clktrk
_______________________________________________
Sesame-general mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/sesame-general
Reply | Threaded
Open this post in threaded view
|

Re: how to address the Graph Store's default graph in a SPARQL QUERY

Jeen Broekstra
In reply to this post by Barry Norton-2
On 1/11/13 7:20 am, Barry Norton wrote:
>
> I believe he wants to address only the null context via SPARQL. Which
> you can't (as I remember).

Actually, since Sesame 2.7, the SPARQL parser accepts both "FROM
DEFAULT" and "FROM sesame:nil" to address the null context. These are
experimental though, which is why they're not widely advertised.

"FROM DEFAULT" was also proposed as an extension to the standard for the
SPARQL WG. That proposal was rejected, which means that we will be
removing it again in Sesame 2.8. However, "sesame:nil" will remain as a
Sesame-specific feature in the SPARQL parser. See
https://openrdf.atlassian.net/browse/SES-850 .

So, if you want to use one of these, use "FROM sesame:nil".

I agree though that if at all possible, it's preferable not to use this
extension, and instead set up your repository/dataset in such a way that
data you need to address specifically is always in an appropriate named
graph, instead.

Jeen


------------------------------------------------------------------------------
Android is increasing in popularity, but the open development platform that
developers love is also attractive to malware creators. Download this white
paper to learn more about secure code signing practices that can help keep
Android apps secure.
http://pubads.g.doubleclick.net/gampad/clk?id=65839951&iu=/4140/ostg.clktrk
_______________________________________________
Sesame-general mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/sesame-general
Reply | Threaded
Open this post in threaded view
|

Re: how to address the Graph Store's default graph in a SPARQL QUERY

Jeen Broekstra
In reply to this post by Mike Grove-2
On 1/11/13 8:26 am, Mike Grove wrote:

> On Thu, Oct 31, 2013 at 2:40 PM, Barry Norton <[hidden email]
> <mailto:[hidden email]>> wrote:
>
>
>     I'm with you 100%.
>
>     One of my training mantras is: do not put explicit assertions in the
>     [null context].
>
>
> I'll respectively disagree on that point.  It's not clear that gives you
> any particular advantage.
>
> wrt to the OP's question, "FROM DEFAULT" parses with the Sesame SPARQL
> parser just fine, and, afaict, works as expected.  It seems like a
> usable workaround to the fact that, by default, Sesame considers the
> active graph for query evaluation to be the union of the default context
> & all named graphs.

Just as a quick heads up: FROM DEFAULT was introduced as a proposal for
extending the SPARQL standard, which was rejected by the WG. We are
planning to remove it from the parser again. However, "FROM sesame:nil"
serves the same purpose.

Jeen



------------------------------------------------------------------------------
Android is increasing in popularity, but the open development platform that
developers love is also attractive to malware creators. Download this white
paper to learn more about secure code signing practices that can help keep
Android apps secure.
http://pubads.g.doubleclick.net/gampad/clk?id=65839951&iu=/4140/ostg.clktrk
_______________________________________________
Sesame-general mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/sesame-general
Reply | Threaded
Open this post in threaded view
|

Re: how to address the Graph Store's default graph in a SPARQL QUERY

Mike Grove-2



On Thu, Oct 31, 2013 at 3:43 PM, Jeen Broekstra <[hidden email]> wrote:
On 1/11/13 8:26 am, Mike Grove wrote:
> On Thu, Oct 31, 2013 at 2:40 PM, Barry Norton <[hidden email]
> <mailto:[hidden email]>> wrote:
>
>
>     I'm with you 100%.
>
>     One of my training mantras is: do not put explicit assertions in the
>     [null context].
>
>
> I'll respectively disagree on that point.  It's not clear that gives you
> any particular advantage.
>
> wrt to the OP's question, "FROM DEFAULT" parses with the Sesame SPARQL
> parser just fine, and, afaict, works as expected.  It seems like a
> usable workaround to the fact that, by default, Sesame considers the
> active graph for query evaluation to be the union of the default context
> & all named graphs.

Just as a quick heads up: FROM DEFAULT was introduced as a proposal for
extending the SPARQL standard, which was rejected by the WG. We are
planning to remove it from the parser again. However, "FROM sesame:nil"
serves the same purpose.

Yep, this is what the parsed query reflects, the default graph has a single URI, sesame:nil.

I'd argue that FROM DEFAULT should stay, I think that's more clear and easier to use.  And I just implemented support for it, so I dont want to revert my commit! =)

Cheers,

Mike
 

Jeen



------------------------------------------------------------------------------
Android is increasing in popularity, but the open development platform that
developers love is also attractive to malware creators. Download this white
paper to learn more about secure code signing practices that can help keep
Android apps secure.
http://pubads.g.doubleclick.net/gampad/clk?id=65839951&iu=/4140/ostg.clktrk
_______________________________________________
Sesame-general mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/sesame-general


------------------------------------------------------------------------------
Android is increasing in popularity, but the open development platform that
developers love is also attractive to malware creators. Download this white
paper to learn more about secure code signing practices that can help keep
Android apps secure.
http://pubads.g.doubleclick.net/gampad/clk?id=65839951&iu=/4140/ostg.clktrk
_______________________________________________
Sesame-general mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/sesame-general
Reply | Threaded
Open this post in threaded view
|

Re: how to address the Graph Store's default graph in a SPARQL QUERY

Jeen Broekstra
On 1/11/13 8:46 am, Mike Grove wrote:

> I'd argue that FROM DEFAULT should stay, I think that's more clear and
> easier to use.  And I just implemented support for it, so I dont want to
> revert my commit! =)

I actually find it less clear, funnily enough. In addition, I'm hesitant
about adding non-standard keywords to the language that are not
obviously implementation-specific ("sesame:nil" is rather obviously a
Sesame feature, while "FROM DEFAULT" could easily be mistaken for a
generic SPARQL feature).

But perhaps the cat's out of the bag (we already added it, you're
already using it) and I should just accept that and move on :)


Jeen


------------------------------------------------------------------------------
Android is increasing in popularity, but the open development platform that
developers love is also attractive to malware creators. Download this white
paper to learn more about secure code signing practices that can help keep
Android apps secure.
http://pubads.g.doubleclick.net/gampad/clk?id=65839951&iu=/4140/ostg.clktrk
_______________________________________________
Sesame-general mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/sesame-general
Reply | Threaded
Open this post in threaded view
|

Re: how to address the Graph Store's default graph in a SPARQL QUERY

Barry Norton-2
In reply to this post by Mike Grove-2

 

You would deliberately put your data where it’s not fully accessible by the standard?!

 

Note that this is even more of an issue with deletion (you can’t identify it with a quad pattern and a triple pattern deletes the statement from all contexts).

 

Barry

 

 

 

From: Mike Grove [mailto:[hidden email]]
Sent: 31 October 2013 19:26
To: Sesame discussion list
Subject: Re: [Sesame] how to address the Graph Store's default graph in a SPARQL QUERY

 

On Thu, Oct 31, 2013 at 2:40 PM, Barry Norton <[hidden email]> wrote:


I'm with you 100%.

One of my training mantras is: do not put explicit assertions in the [null context].

 

I'll respectively disagree on that point.  It's not clear that gives you any particular advantage.

 

wrt to the OP's question, "FROM DEFAULT" parses with the Sesame SPARQL parser just fine, and, afaict, works as expected.  It seems like a usable workaround to the fact that, by default, Sesame considers the active graph for query evaluation to be the union of the default context & all named graphs.

 

Cheers,

 

Mike

 


Barry


-----Original Message-----
From: David Booth [mailto:[hidden email]]

Sent: 31 October 2013 18:37
To: Sesame discussion list
Subject: Re: [Sesame] how to address the Graph Store's default graph in a SPARQL QUERY

Oh, I see.  Then AFAIK the best work-around is to not use the null context.  Give it an explicit name instead.

David

On 10/31/2013 02:20 PM, Barry Norton wrote:
>
> I believe he wants to address only the null context via SPARQL. Which
> you can't (as I remember).
>
> Barry
>
>
>
> -----Original Message----- From: David Booth [mailto:[hidden email]]
> Sent: 31 October 2013 18:18 To: Sesame discussion list Subject: Re:
> [Sesame] how to address the Graph Store's default graph in a SPARQL
> QUERY
>
> Hi Armando,
>
> I'm not entirely sure that I understand your question, but SPARQL 1.1
> Query has notions of:
>
> - the *default* graph, which will either consist of the merge of named
> graphs that are specified using the FROM syntax; or it will consist of
> somewhat unspecified content that *may* (by default) consist of the
> merge of all of the named graphs in the store (but IIRC this is not
> required by the standard).
> http://www.w3.org/TR/sparql11-query/#unnamedGraph
>
> - the *active* graph, which is the graph against which a particular
> triple pattern will be matched, and may be either the default graph or
> a specifi named graph (if the GRAPH keyword is used).
> http://www.w3.org/TR/sparql11-query/#rdfDataset
>
> Does that help?
>
> David
>
> On 10/31/2013 12:31 PM, Armando Stellato wrote:
>> Dear all,
>>
>> The issue is: through the Sesame2 Repository API, I'm able to
>> retrieve statements from the null context only. I can't do this
>> through SPARQL (not simply at least).
>>
>> I looked for previous posts about this before sending this email:
>>
>> So far, most of the stuff is here:
>>
>> [1] http://www.openrdf.org/forum/mvnforum/viewthread?thread=1518
>>
>> [2] http://www.openrdf.org/issues/browse/SES-848
>>
>> [3] http://www.openrdf.org/issues/browse/SES-849
>>
>> [4] https://openrdf.atlassian.net/browse/SES-850
>>
>> I read about your solution, with sesame:nil, and the proposal you
>> made for standardizing this in SPARQL, with FROM DEFAULT(rejected).
>> Thus, I thought it was an idiosyncrasy between the notion of null
>> context in Sesame2 which maybe is not so close to the notion of
>> default graph in SPARQL.
>>
>> I thus decided to forget about technology, and see at least how the
>> problem is addressed in SPARQL.
>>
>> The SPARQL specifications are rather weird in this:
>>
>> 1) SPARQL 1.1 QUERY specifications define an RDF Dataset's /default
>> graph/ as a defineable graph (scoped to the query) which is either:
>>
>> a) the "RDF Merge" of all named graphs, IFF no FROM/FROM NAMED clause
>> is given
>>
>> b) the dynamic "RDF Merge" of the sole graphs specified in one or
>> more FROM clause
>>
>> 2) SPARQL 1.1 UPDATE specifications define a "Graph Store" 's
>> /default graph/ as the unique "UNNAMED GRAPH" in the store. If no
>> graph is specified in an update, the information is stored in the
>> unnamed graph. A Graph Store's default graph seems to be in a 1-1
>> relationship with the Sesame's null context
>>
>> So, issue is: how to indicate the "Graph Store"'s default graph in a
>> SPARQL QUERY? There seems to be no link among them! SPARQL UPDATE
>> seems to define something (Graph Store's default graph) very close to
>> the null context of Sesame2, while SPARQL QUERY has its own
>> definition of default graph (RDF Dataset's one), but no way to
>> explicitly access the triples in the Graph Store's default graph.
>>
>> Am I missing anything?
>>
>> Cheers,
>>
>> Armando
>>
>> P.S: btw, I tried to use the sesame:nil graph, but no results. I'm
>> using sesame 2.6.8, which was supposed to include it, unless it has
>> been trashed later. Is the namespace the usual one?
>> http://www.openrdf.org/schema/sesame#
>>
>> P.P.S: I know we can obtain this through proper use of !BOUND, MINUS,
>> NOT EXISTS etc... just I'm puzzled by the fact that there is no
>> shorter and more explicit solution (and possibly defined at SPARQL
>> level, not using any store's specific extension). This hinders
>> simplicity of code, other than performance...
>>
>> --------------------------------------------------
>>
>> Ing. Armando Stellato, PhD
>>
>> AI Research Group,
>>
>> Dept. of Enterprise Engineering
>>
>> University of Roma, Tor Vergata
>>
>> Via del Politecnico 1 00133 ROMA (ITALY)
>>
>> tel: <a href="tel:%2B39%2006%207259%207330">+39 06 7259 7330 (office, room A1-14);
>>
>> <a href="tel:%2B39%2006%207259%207332">+39 06 7259 7332 (lab)
>>
>> fax: <a href="tel:%2B39%2006%207259%207460">+39 06 7259 7460
>>
>> e_mail: [hidden email]
>> <mailto:[hidden email]>
>>
>> --------------------------------------------------
>>
>>
>>
>> ---------------------------------------------------------------------
>> -
>>
>>
-------- Android is increasing in popularity, but the open development
>> platform that developers love is also attractive to malware creators.
>> Download this white paper to learn more about secure code signing
>> practices that can help keep Android apps secure.
>> http://pubads.g.doubleclick.net/gampad/clk?id=65839951&iu=/4140/ostg.
>> c
>>
>>
lktrk
>>
>>
>>
>> _______________________________________________ Sesame-general
>> mailing list [hidden email]
>> https://lists.sourceforge.net/lists/listinfo/sesame-general
>>
>
> ----------------------------------------------------------------------
> --------
>
>
Android is increasing in popularity, but the open development platform that developers love is also attractive to malware creators. Download this white paper to learn more about secure code signing practices that can help keep Android apps secure.
> http://pubads.g.doubleclick.net/gampad/clk?id=65839951&iu=/4140/ostg.c
> lktrk
>
>
_______________________________________________
> Sesame-general mailing list [hidden email]
> https://lists.sourceforge.net/lists/listinfo/sesame-general
>
> ----------------------------------------------------------------------
> --------
>
>
Android is increasing in popularity, but the open development platform that
> developers love is also attractive to malware creators. Download this
> white paper to learn more about secure code signing practices that can
> help keep Android apps secure.
> http://pubads.g.doubleclick.net/gampad/clk?id=65839951&iu=/4140/ostg.c
> lktrk
>
>
_______________________________________________
> Sesame-general mailing list [hidden email]
> https://lists.sourceforge.net/lists/listinfo/sesame-general
>
>
>

------------------------------------------------------------------------------
Android is increasing in popularity, but the open development platform that developers love is also attractive to malware creators. Download this white paper to learn more about secure code signing practices that can help keep Android apps secure.
http://pubads.g.doubleclick.net/gampad/clk?id=65839951&iu=/4140/ostg.clktrk
_______________________________________________
Sesame-general mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/sesame-general

------------------------------------------------------------------------------
Android is increasing in popularity, but the open development platform that
developers love is also attractive to malware creators. Download this white
paper to learn more about secure code signing practices that can help keep
Android apps secure.
http://pubads.g.doubleclick.net/gampad/clk?id=65839951&iu=/4140/ostg.clktrk
_______________________________________________
Sesame-general mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/sesame-general

 


------------------------------------------------------------------------------
Android is increasing in popularity, but the open development platform that
developers love is also attractive to malware creators. Download this white
paper to learn more about secure code signing practices that can help keep
Android apps secure.
http://pubads.g.doubleclick.net/gampad/clk?id=65839951&iu=/4140/ostg.clktrk
_______________________________________________
Sesame-general mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/sesame-general
Reply | Threaded
Open this post in threaded view
|

Re: how to address the Graph Store's default graph in a SPARQL QUERY

Mike Grove-2

On Fri, Nov 1, 2013 at 6:22 AM, Barry Norton <[hidden email]> wrote:

 

You would deliberately put your data where it’s not fully accessible by the standard?!


lol, you're too funny.
 

 

Note that this is even more of an issue with deletion (you can’t identify it with a quad pattern and a triple pattern deletes the statement from all contexts).


eh, not really.  That might be what Sesame chooses, but that's not what the standard dictates.  Frankly I think the decision that the active graph, when nothing else is specified, is the entire database is wrong.  It leads to (imo) more problems than it solves, and using a pseudo-graph, say sesame:all, is more clear than having to use one for the default graph.
 

 

Barry

 

 

 

From: Mike Grove [mailto:[hidden email]]
Sent: 31 October 2013 19:26


To: Sesame discussion list
Subject: Re: [Sesame] how to address the Graph Store's default graph in a SPARQL QUERY

 

On Thu, Oct 31, 2013 at 2:40 PM, Barry Norton <[hidden email]> wrote:


I'm with you 100%.

One of my training mantras is: do not put explicit assertions in the [null context].

 

I'll respectively disagree on that point.  It's not clear that gives you any particular advantage.

 

wrt to the OP's question, "FROM DEFAULT" parses with the Sesame SPARQL parser just fine, and, afaict, works as expected.  It seems like a usable workaround to the fact that, by default, Sesame considers the active graph for query evaluation to be the union of the default context & all named graphs.

 

Cheers,

 

Mike

 


Barry


-----Original Message-----
From: David Booth [mailto:[hidden email]]

Sent: 31 October 2013 18:37
To: Sesame discussion list
Subject: Re: [Sesame] how to address the Graph Store's default graph in a SPARQL QUERY

Oh, I see.  Then AFAIK the best work-around is to not use the null context.  Give it an explicit name instead.

David

On 10/31/2013 02:20 PM, Barry Norton wrote:
>
> I believe he wants to address only the null context via SPARQL. Which
> you can't (as I remember).
>
> Barry
>
>
>
> -----Original Message----- From: David Booth [mailto:[hidden email]]
> Sent: 31 October 2013 18:18 To: Sesame discussion list Subject: Re:
> [Sesame] how to address the Graph Store's default graph in a SPARQL
> QUERY
>
> Hi Armando,
>
> I'm not entirely sure that I understand your question, but SPARQL 1.1
> Query has notions of:
>
> - the *default* graph, which will either consist of the merge of named
> graphs that are specified using the FROM syntax; or it will consist of
> somewhat unspecified content that *may* (by default) consist of the
> merge of all of the named graphs in the store (but IIRC this is not
> required by the standard).
> http://www.w3.org/TR/sparql11-query/#unnamedGraph
>
> - the *active* graph, which is the graph against which a particular
> triple pattern will be matched, and may be either the default graph or
> a specifi named graph (if the GRAPH keyword is used).
> http://www.w3.org/TR/sparql11-query/#rdfDataset
>
> Does that help?
>
> David
>
> On 10/31/2013 12:31 PM, Armando Stellato wrote:
>> Dear all,
>>
>> The issue is: through the Sesame2 Repository API, I'm able to
>> retrieve statements from the null context only. I can't do this
>> through SPARQL (not simply at least).
>>
>> I looked for previous posts about this before sending this email:
>>
>> So far, most of the stuff is here:
>>
>> [1] http://www.openrdf.org/forum/mvnforum/viewthread?thread=1518
>>
>> [2] http://www.openrdf.org/issues/browse/SES-848
>>
>> [3] http://www.openrdf.org/issues/browse/SES-849
>>
>> [4] https://openrdf.atlassian.net/browse/SES-850
>>
>> I read about your solution, with sesame:nil, and the proposal you
>> made for standardizing this in SPARQL, with FROM DEFAULT(rejected).
>> Thus, I thought it was an idiosyncrasy between the notion of null
>> context in Sesame2 which maybe is not so close to the notion of
>> default graph in SPARQL.
>>
>> I thus decided to forget about technology, and see at least how the
>> problem is addressed in SPARQL.
>>
>> The SPARQL specifications are rather weird in this:
>>
>> 1) SPARQL 1.1 QUERY specifications define an RDF Dataset's /default
>> graph/ as a defineable graph (scoped to the query) which is either:
>>
>> a) the "RDF Merge" of all named graphs, IFF no FROM/FROM NAMED clause
>> is given
>>
>> b) the dynamic "RDF Merge" of the sole graphs specified in one or
>> more FROM clause
>>
>> 2) SPARQL 1.1 UPDATE specifications define a "Graph Store" 's
>> /default graph/ as the unique "UNNAMED GRAPH" in the store. If no
>> graph is specified in an update, the information is stored in the
>> unnamed graph. A Graph Store's default graph seems to be in a 1-1
>> relationship with the Sesame's null context
>>
>> So, issue is: how to indicate the "Graph Store"'s default graph in a
>> SPARQL QUERY? There seems to be no link among them! SPARQL UPDATE
>> seems to define something (Graph Store's default graph) very close to
>> the null context of Sesame2, while SPARQL QUERY has its own
>> definition of default graph (RDF Dataset's one), but no way to
>> explicitly access the triples in the Graph Store's default graph.
>>
>> Am I missing anything?
>>
>> Cheers,
>>
>> Armando
>>
>> P.S: btw, I tried to use the sesame:nil graph, but no results. I'm
>> using sesame 2.6.8, which was supposed to include it, unless it has
>> been trashed later. Is the namespace the usual one?
>> http://www.openrdf.org/schema/sesame#
>>
>> P.P.S: I know we can obtain this through proper use of !BOUND, MINUS,
>> NOT EXISTS etc... just I'm puzzled by the fact that there is no
>> shorter and more explicit solution (and possibly defined at SPARQL
>> level, not using any store's specific extension). This hinders
>> simplicity of code, other than performance...
>>
>> --------------------------------------------------
>>
>> Ing. Armando Stellato, PhD
>>
>> AI Research Group,
>>
>> Dept. of Enterprise Engineering
>>
>> University of Roma, Tor Vergata
>>
>> Via del Politecnico 1 00133 ROMA (ITALY)
>>
>> tel: <a href="tel:%2B39%2006%207259%207330" target="_blank">+39 06 7259 7330 (office, room A1-14);
>>
>> <a href="tel:%2B39%2006%207259%207332" target="_blank">+39 06 7259 7332 (lab)
>>
>> fax: <a href="tel:%2B39%2006%207259%207460" target="_blank">+39 06 7259 7460
>>
>> e_mail: [hidden email]
>> <mailto:[hidden email]>
>>
>> --------------------------------------------------
>>
>>
>>
>> ---------------------------------------------------------------------
>> -
>>
>>
-------- Android is increasing in popularity, but the open development
>> platform that developers love is also attractive to malware creators.
>> Download this white paper to learn more about secure code signing
>> practices that can help keep Android apps secure.
>> http://pubads.g.doubleclick.net/gampad/clk?id=65839951&iu=/4140/ostg.
>> c
>>
>>
lktrk
>>
>>
>>
>> _______________________________________________ Sesame-general
>> mailing list [hidden email]
>> https://lists.sourceforge.net/lists/listinfo/sesame-general
>>
>
> ----------------------------------------------------------------------
> --------
>
>
Android is increasing in popularity, but the open development platform that developers love is also attractive to malware creators. Download this white paper to learn more about secure code signing practices that can help keep Android apps secure.
> http://pubads.g.doubleclick.net/gampad/clk?id=65839951&iu=/4140/ostg.c
> lktrk
>
>
_______________________________________________
> Sesame-general mailing list [hidden email]
> https://lists.sourceforge.net/lists/listinfo/sesame-general
>
> ----------------------------------------------------------------------
> --------
>
>
Android is increasing in popularity, but the open development platform that
> developers love is also attractive to malware creators. Download this
> white paper to learn more about secure code signing practices that can
> help keep Android apps secure.
> http://pubads.g.doubleclick.net/gampad/clk?id=65839951&iu=/4140/ostg.c
> lktrk
>
>
_______________________________________________
> Sesame-general mailing list [hidden email]
> https://lists.sourceforge.net/lists/listinfo/sesame-general
>
>
>

------------------------------------------------------------------------------
Android is increasing in popularity, but the open development platform that developers love is also attractive to malware creators. Download this white paper to learn more about secure code signing practices that can help keep Android apps secure.
http://pubads.g.doubleclick.net/gampad/clk?id=65839951&iu=/4140/ostg.clktrk
_______________________________________________
Sesame-general mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/sesame-general

------------------------------------------------------------------------------
Android is increasing in popularity, but the open development platform that
developers love is also attractive to malware creators. Download this white
paper to learn more about secure code signing practices that can help keep
Android apps secure.
http://pubads.g.doubleclick.net/gampad/clk?id=65839951&iu=/4140/ostg.clktrk
_______________________________________________
Sesame-general mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/sesame-general

 


------------------------------------------------------------------------------
Android is increasing in popularity, but the open development platform that
developers love is also attractive to malware creators. Download this white
paper to learn more about secure code signing practices that can help keep
Android apps secure.
http://pubads.g.doubleclick.net/gampad/clk?id=65839951&iu=/4140/ostg.clktrk
_______________________________________________
Sesame-general mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/sesame-general



------------------------------------------------------------------------------
Android is increasing in popularity, but the open development platform that
developers love is also attractive to malware creators. Download this white
paper to learn more about secure code signing practices that can help keep
Android apps secure.
http://pubads.g.doubleclick.net/gampad/clk?id=65839951&iu=/4140/ostg.clktrk
_______________________________________________
Sesame-general mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/sesame-general
Reply | Threaded
Open this post in threaded view
|

Re: how to address the Graph Store's default graph in a SPARQL QUERY

Barry Norton-2

 

Well I’m glad to amuse but, seriously, the non-portable solutions to corner cases like the null context (and blank node-‘named’ graphs – thanks, Sesame, for encouraging this) are best avoided by good practice recommendations in my opinion.

 

It’s like the good old days of certain databases allowing spaces in table names when others didn’t. Just avoid it.

 

Barry

 

 

From: Mike Grove [mailto:[hidden email]]
Sent: 01 November 2013 10:50
To: Sesame discussion list
Subject: Re: [Sesame] how to address the Graph Store's default graph in a SPARQL QUERY

 

 

On Fri, Nov 1, 2013 at 6:22 AM, Barry Norton <[hidden email]> wrote:

 

You would deliberately put your data where it’s not fully accessible by the standard?!

 

lol, you're too funny.

 

 

Note that this is even more of an issue with deletion (you can’t identify it with a quad pattern and a triple pattern deletes the statement from all contexts).

 

eh, not really.  That might be what Sesame chooses, but that's not what the standard dictates.  Frankly I think the decision that the active graph, when nothing else is specified, is the entire database is wrong.  It leads to (imo) more problems than it solves, and using a pseudo-graph, say sesame:all, is more clear than having to use one for the default graph.

 

 

Barry

 

 

 

From: Mike Grove [mailto:[hidden email]]
Sent: 31 October 2013 19:26


To: Sesame discussion list
Subject: Re: [Sesame] how to address the Graph Store's default graph in a SPARQL QUERY

 

On Thu, Oct 31, 2013 at 2:40 PM, Barry Norton <[hidden email]> wrote:


I'm with you 100%.

One of my training mantras is: do not put explicit assertions in the [null context].

 

I'll respectively disagree on that point.  It's not clear that gives you any particular advantage.

 

wrt to the OP's question, "FROM DEFAULT" parses with the Sesame SPARQL parser just fine, and, afaict, works as expected.  It seems like a usable workaround to the fact that, by default, Sesame considers the active graph for query evaluation to be the union of the default context & all named graphs.

 

Cheers,

 

Mike

 


Barry


-----Original Message-----
From: David Booth [mailto:[hidden email]]

Sent: 31 October 2013 18:37
To: Sesame discussion list
Subject: Re: [Sesame] how to address the Graph Store's default graph in a SPARQL QUERY

Oh, I see.  Then AFAIK the best work-around is to not use the null context.  Give it an explicit name instead.

David

On 10/31/2013 02:20 PM, Barry Norton wrote:
>
> I believe he wants to address only the null context via SPARQL. Which
> you can't (as I remember).
>
> Barry
>
>
>
> -----Original Message----- From: David Booth [mailto:[hidden email]]
> Sent: 31 October 2013 18:18 To: Sesame discussion list Subject: Re:
> [Sesame] how to address the Graph Store's default graph in a SPARQL
> QUERY
>
> Hi Armando,
>
> I'm not entirely sure that I understand your question, but SPARQL 1.1
> Query has notions of:
>
> - the *default* graph, which will either consist of the merge of named
> graphs that are specified using the FROM syntax; or it will consist of
> somewhat unspecified content that *may* (by default) consist of the
> merge of all of the named graphs in the store (but IIRC this is not
> required by the standard).
> http://www.w3.org/TR/sparql11-query/#unnamedGraph
>
> - the *active* graph, which is the graph against which a particular
> triple pattern will be matched, and may be either the default graph or
> a specifi named graph (if the GRAPH keyword is used).
> http://www.w3.org/TR/sparql11-query/#rdfDataset
>
> Does that help?
>
> David
>
> On 10/31/2013 12:31 PM, Armando Stellato wrote:
>> Dear all,
>>
>> The issue is: through the Sesame2 Repository API, I'm able to
>> retrieve statements from the null context only. I can't do this
>> through SPARQL (not simply at least).
>>
>> I looked for previous posts about this before sending this email:
>>
>> So far, most of the stuff is here:
>>
>> [1] http://www.openrdf.org/forum/mvnforum/viewthread?thread=1518
>>
>> [2] http://www.openrdf.org/issues/browse/SES-848
>>
>> [3] http://www.openrdf.org/issues/browse/SES-849
>>
>> [4] https://openrdf.atlassian.net/browse/SES-850
>>
>> I read about your solution, with sesame:nil, and the proposal you
>> made for standardizing this in SPARQL, with FROM DEFAULT(rejected).
>> Thus, I thought it was an idiosyncrasy between the notion of null
>> context in Sesame2 which maybe is not so close to the notion of
>> default graph in SPARQL.
>>
>> I thus decided to forget about technology, and see at least how the
>> problem is addressed in SPARQL.
>>
>> The SPARQL specifications are rather weird in this:
>>
>> 1) SPARQL 1.1 QUERY specifications define an RDF Dataset's /default
>> graph/ as a defineable graph (scoped to the query) which is either:
>>
>> a) the "RDF Merge" of all named graphs, IFF no FROM/FROM NAMED clause
>> is given
>>
>> b) the dynamic "RDF Merge" of the sole graphs specified in one or
>> more FROM clause
>>
>> 2) SPARQL 1.1 UPDATE specifications define a "Graph Store" 's
>> /default graph/ as the unique "UNNAMED GRAPH" in the store. If no
>> graph is specified in an update, the information is stored in the
>> unnamed graph. A Graph Store's default graph seems to be in a 1-1
>> relationship with the Sesame's null context
>>
>> So, issue is: how to indicate the "Graph Store"'s default graph in a
>> SPARQL QUERY? There seems to be no link among them! SPARQL UPDATE
>> seems to define something (Graph Store's default graph) very close to
>> the null context of Sesame2, while SPARQL QUERY has its own
>> definition of default graph (RDF Dataset's one), but no way to
>> explicitly access the triples in the Graph Store's default graph.
>>
>> Am I missing anything?
>>
>> Cheers,
>>
>> Armando
>>
>> P.S: btw, I tried to use the sesame:nil graph, but no results. I'm
>> using sesame 2.6.8, which was supposed to include it, unless it has
>> been trashed later. Is the namespace the usual one?
>> http://www.openrdf.org/schema/sesame#
>>
>> P.P.S: I know we can obtain this through proper use of !BOUND, MINUS,
>> NOT EXISTS etc... just I'm puzzled by the fact that there is no
>> shorter and more explicit solution (and possibly defined at SPARQL
>> level, not using any store's specific extension). This hinders
>> simplicity of code, other than performance...
>>
>> --------------------------------------------------
>>
>> Ing. Armando Stellato, PhD
>>
>> AI Research Group,
>>
>> Dept. of Enterprise Engineering
>>
>> University of Roma, Tor Vergata
>>
>> Via del Politecnico 1 00133 ROMA (ITALY)
>>
>> tel: <a href="tel:%2B39%2006%207259%207330" target="_blank">+39 06 7259 7330 (office, room A1-14);
>>
>> <a href="tel:%2B39%2006%207259%207332" target="_blank">+39 06 7259 7332 (lab)
>>
>> fax: <a href="tel:%2B39%2006%207259%207460" target="_blank">+39 06 7259 7460
>>
>> e_mail: [hidden email]
>> <mailto:[hidden email]>
>>
>> --------------------------------------------------
>>
>>
>>
>> ---------------------------------------------------------------------
>> -
>>
>>
-------- Android is increasing in popularity, but the open development
>> platform that developers love is also attractive to malware creators.
>> Download this white paper to learn more about secure code signing
>> practices that can help keep Android apps secure.
>> http://pubads.g.doubleclick.net/gampad/clk?id=65839951&iu=/4140/ostg.
>> c
>>
>>
lktrk
>>
>>
>>
>> _______________________________________________ Sesame-general
>> mailing list [hidden email]
>> https://lists.sourceforge.net/lists/listinfo/sesame-general
>>
>
> ----------------------------------------------------------------------
> --------
>
>
Android is increasing in popularity, but the open development platform that developers love is also attractive to malware creators. Download this white paper to learn more about secure code signing practices that can help keep Android apps secure.
> http://pubads.g.doubleclick.net/gampad/clk?id=65839951&iu=/4140/ostg.c
> lktrk
>
>
_______________________________________________
> Sesame-general mailing list [hidden email]
> https://lists.sourceforge.net/lists/listinfo/sesame-general
>
> ----------------------------------------------------------------------
> --------
>
>
Android is increasing in popularity, but the open development platform that
> developers love is also attractive to malware creators. Download this
> white paper to learn more about secure code signing practices that can
> help keep Android apps secure.
> http://pubads.g.doubleclick.net/gampad/clk?id=65839951&iu=/4140/ostg.c
> lktrk
>
>
_______________________________________________
> Sesame-general mailing list [hidden email]
> https://lists.sourceforge.net/lists/listinfo/sesame-general
>
>
>

------------------------------------------------------------------------------
Android is increasing in popularity, but the open development platform that developers love is also attractive to malware creators. Download this white paper to learn more about secure code signing practices that can help keep Android apps secure.
http://pubads.g.doubleclick.net/gampad/clk?id=65839951&iu=/4140/ostg.clktrk
_______________________________________________
Sesame-general mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/sesame-general

------------------------------------------------------------------------------
Android is increasing in popularity, but the open development platform that
developers love is also attractive to malware creators. Download this white
paper to learn more about secure code signing practices that can help keep
Android apps secure.
http://pubads.g.doubleclick.net/gampad/clk?id=65839951&iu=/4140/ostg.clktrk
_______________________________________________
Sesame-general mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/sesame-general

 


------------------------------------------------------------------------------
Android is increasing in popularity, but the open development platform that
developers love is also attractive to malware creators. Download this white
paper to learn more about secure code signing practices that can help keep
Android apps secure.
http://pubads.g.doubleclick.net/gampad/clk?id=65839951&iu=/4140/ostg.clktrk
_______________________________________________
Sesame-general mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/sesame-general

 


------------------------------------------------------------------------------
Android is increasing in popularity, but the open development platform that
developers love is also attractive to malware creators. Download this white
paper to learn more about secure code signing practices that can help keep
Android apps secure.
http://pubads.g.doubleclick.net/gampad/clk?id=65839951&iu=/4140/ostg.clktrk
_______________________________________________
Sesame-general mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/sesame-general
Reply | Threaded
Open this post in threaded view
|

Re: how to address the Graph Store's default graph in a SPARQL QUERY

Mike Grove-2
On Fri, Nov 1, 2013 at 7:00 AM, Barry Norton <[hidden email]> wrote:

 

Well I’m glad to amuse but, seriously, the non-portable solutions to corner cases like the null context (and blank node-‘named’ graphs – thanks, Sesame, for encouraging this) are best avoided by good practice recommendations in my opinion.


That's odd that you think the default no-name context of an RDF database is a corner case.
 

 

It’s like the good old days of certain databases allowing spaces in table names when others didn’t. Just avoid it.

 

Barry

 

 

From: Mike Grove [mailto:[hidden email]]
Sent: 01 November 2013 10:50


To: Sesame discussion list
Subject: Re: [Sesame] how to address the Graph Store's default graph in a SPARQL QUERY

 

 

On Fri, Nov 1, 2013 at 6:22 AM, Barry Norton <[hidden email]> wrote:

 

You would deliberately put your data where it’s not fully accessible by the standard?!

 

lol, you're too funny.

 

 

Note that this is even more of an issue with deletion (you can’t identify it with a quad pattern and a triple pattern deletes the statement from all contexts).

 

eh, not really.  That might be what Sesame chooses, but that's not what the standard dictates.  Frankly I think the decision that the active graph, when nothing else is specified, is the entire database is wrong.  It leads to (imo) more problems than it solves, and using a pseudo-graph, say sesame:all, is more clear than having to use one for the default graph.

 

 

Barry

 

 

 

From: Mike Grove [mailto:[hidden email]]
Sent: 31 October 2013 19:26


To: Sesame discussion list
Subject: Re: [Sesame] how to address the Graph Store's default graph in a SPARQL QUERY

 

On Thu, Oct 31, 2013 at 2:40 PM, Barry Norton <[hidden email]> wrote:


I'm with you 100%.

One of my training mantras is: do not put explicit assertions in the [null context].

 

I'll respectively disagree on that point.  It's not clear that gives you any particular advantage.

 

wrt to the OP's question, "FROM DEFAULT" parses with the Sesame SPARQL parser just fine, and, afaict, works as expected.  It seems like a usable workaround to the fact that, by default, Sesame considers the active graph for query evaluation to be the union of the default context & all named graphs.

 

Cheers,

 

Mike

 


Barry


-----Original Message-----
From: David Booth [mailto:[hidden email]]

Sent: 31 October 2013 18:37
To: Sesame discussion list
Subject: Re: [Sesame] how to address the Graph Store's default graph in a SPARQL QUERY

Oh, I see.  Then AFAIK the best work-around is to not use the null context.  Give it an explicit name instead.

David

On 10/31/2013 02:20 PM, Barry Norton wrote:
>
> I believe he wants to address only the null context via SPARQL. Which
> you can't (as I remember).
>
> Barry
>
>
>
> -----Original Message----- From: David Booth [mailto:[hidden email]]
> Sent: 31 October 2013 18:18 To: Sesame discussion list Subject: Re:
> [Sesame] how to address the Graph Store's default graph in a SPARQL
> QUERY
>
> Hi Armando,
>
> I'm not entirely sure that I understand your question, but SPARQL 1.1
> Query has notions of:
>
> - the *default* graph, which will either consist of the merge of named
> graphs that are specified using the FROM syntax; or it will consist of
> somewhat unspecified content that *may* (by default) consist of the
> merge of all of the named graphs in the store (but IIRC this is not
> required by the standard).
> http://www.w3.org/TR/sparql11-query/#unnamedGraph
>
> - the *active* graph, which is the graph against which a particular
> triple pattern will be matched, and may be either the default graph or
> a specifi named graph (if the GRAPH keyword is used).
> http://www.w3.org/TR/sparql11-query/#rdfDataset
>
> Does that help?
>
> David
>
> On 10/31/2013 12:31 PM, Armando Stellato wrote:
>> Dear all,
>>
>> The issue is: through the Sesame2 Repository API, I'm able to
>> retrieve statements from the null context only. I can't do this
>> through SPARQL (not simply at least).
>>
>> I looked for previous posts about this before sending this email:
>>
>> So far, most of the stuff is here:
>>
>> [1] http://www.openrdf.org/forum/mvnforum/viewthread?thread=1518
>>
>> [2] http://www.openrdf.org/issues/browse/SES-848
>>
>> [3] http://www.openrdf.org/issues/browse/SES-849
>>
>> [4] https://openrdf.atlassian.net/browse/SES-850
>>
>> I read about your solution, with sesame:nil, and the proposal you
>> made for standardizing this in SPARQL, with FROM DEFAULT(rejected).
>> Thus, I thought it was an idiosyncrasy between the notion of null
>> context in Sesame2 which maybe is not so close to the notion of
>> default graph in SPARQL.
>>
>> I thus decided to forget about technology, and see at least how the
>> problem is addressed in SPARQL.
>>
>> The SPARQL specifications are rather weird in this:
>>
>> 1) SPARQL 1.1 QUERY specifications define an RDF Dataset's /default
>> graph/ as a defineable graph (scoped to the query) which is either:
>>
>> a) the "RDF Merge" of all named graphs, IFF no FROM/FROM NAMED clause
>> is given
>>
>> b) the dynamic "RDF Merge" of the sole graphs specified in one or
>> more FROM clause
>>
>> 2) SPARQL 1.1 UPDATE specifications define a "Graph Store" 's
>> /default graph/ as the unique "UNNAMED GRAPH" in the store. If no
>> graph is specified in an update, the information is stored in the
>> unnamed graph. A Graph Store's default graph seems to be in a 1-1
>> relationship with the Sesame's null context
>>
>> So, issue is: how to indicate the "Graph Store"'s default graph in a
>> SPARQL QUERY? There seems to be no link among them! SPARQL UPDATE
>> seems to define something (Graph Store's default graph) very close to
>> the null context of Sesame2, while SPARQL QUERY has its own
>> definition of default graph (RDF Dataset's one), but no way to
>> explicitly access the triples in the Graph Store's default graph.
>>
>> Am I missing anything?
>>
>> Cheers,
>>
>> Armando
>>
>> P.S: btw, I tried to use the sesame:nil graph, but no results. I'm
>> using sesame 2.6.8, which was supposed to include it, unless it has
>> been trashed later. Is the namespace the usual one?
>> http://www.openrdf.org/schema/sesame#
>>
>> P.P.S: I know we can obtain this through proper use of !BOUND, MINUS,
>> NOT EXISTS etc... just I'm puzzled by the fact that there is no
>> shorter and more explicit solution (and possibly defined at SPARQL
>> level, not using any store's specific extension). This hinders
>> simplicity of code, other than performance...
>>
>> --------------------------------------------------
>>
>> Ing. Armando Stellato, PhD
>>
>> AI Research Group,
>>
>> Dept. of Enterprise Engineering
>>
>> University of Roma, Tor Vergata
>>
>> Via del Politecnico 1 00133 ROMA (ITALY)
>>
>> tel: <a href="tel:%2B39%2006%207259%207330" target="_blank">+39 06 7259 7330 (office, room A1-14);
>>
>> <a href="tel:%2B39%2006%207259%207332" target="_blank">+39 06 7259 7332 (lab)
>>
>> fax: <a href="tel:%2B39%2006%207259%207460" target="_blank">+39 06 7259 7460
>>
>> e_mail: [hidden email]
>> <mailto:[hidden email]>
>>
>> --------------------------------------------------
>>
>>
>>
>> ---------------------------------------------------------------------
>> -
>>
>>
-------- Android is increasing in popularity, but the open development
>> platform that developers love is also attractive to malware creators.
>> Download this white paper to learn more about secure code signing
>> practices that can help keep Android apps secure.
>> http://pubads.g.doubleclick.net/gampad/clk?id=65839951&iu=/4140/ostg.
>> c
>>
>>
lktrk
>>
>>
>>
>> _______________________________________________ Sesame-general
>> mailing list [hidden email]
>> https://lists.sourceforge.net/lists/listinfo/sesame-general
>>
>
> ----------------------------------------------------------------------
> --------
>
>
Android is increasing in popularity, but the open development platform that developers love is also attractive to malware creators. Download this white paper to learn more about secure code signing practices that can help keep Android apps secure.
> http://pubads.g.doubleclick.net/gampad/clk?id=65839951&iu=/4140/ostg.c
> lktrk
>
>
_______________________________________________
> Sesame-general mailing list [hidden email]
> https://lists.sourceforge.net/lists/listinfo/sesame-general
>
> ----------------------------------------------------------------------
> --------
>
>
Android is increasing in popularity, but the open development platform that
> developers love is also attractive to malware creators. Download this
> white paper to learn more about secure code signing practices that can
> help keep Android apps secure.
> http://pubads.g.doubleclick.net/gampad/clk?id=65839951&iu=/4140/ostg.c
> lktrk
>
>
_______________________________________________
> Sesame-general mailing list [hidden email]
> https://lists.sourceforge.net/lists/listinfo/sesame-general
>
>
>

------------------------------------------------------------------------------
Android is increasing in popularity, but the open development platform that developers love is also attractive to malware creators. Download this white paper to learn more about secure code signing practices that can help keep Android apps secure.
http://pubads.g.doubleclick.net/gampad/clk?id=65839951&iu=/4140/ostg.clktrk
_______________________________________________
Sesame-general mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/sesame-general

------------------------------------------------------------------------------
Android is increasing in popularity, but the open development platform that
developers love is also attractive to malware creators. Download this white
paper to learn more about secure code signing practices that can help keep
Android apps secure.
http://pubads.g.doubleclick.net/gampad/clk?id=65839951&iu=/4140/ostg.clktrk
_______________________________________________
Sesame-general mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/sesame-general

 


------------------------------------------------------------------------------
Android is increasing in popularity, but the open development platform that
developers love is also attractive to malware creators. Download this white
paper to learn more about secure code signing practices that can help keep
Android apps secure.
http://pubads.g.doubleclick.net/gampad/clk?id=65839951&iu=/4140/ostg.clktrk
_______________________________________________
Sesame-general mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/sesame-general

 


------------------------------------------------------------------------------
Android is increasing in popularity, but the open development platform that
developers love is also attractive to malware creators. Download this white
paper to learn more about secure code signing practices that can help keep
Android apps secure.
http://pubads.g.doubleclick.net/gampad/clk?id=65839951&iu=/4140/ostg.clktrk
_______________________________________________
Sesame-general mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/sesame-general



------------------------------------------------------------------------------
Android is increasing in popularity, but the open development platform that
developers love is also attractive to malware creators. Download this white
paper to learn more about secure code signing practices that can help keep
Android apps secure.
http://pubads.g.doubleclick.net/gampad/clk?id=65839951&iu=/4140/ostg.clktrk
_______________________________________________
Sesame-general mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/sesame-general
Reply | Threaded
Open this post in threaded view
|

Re: how to address the Graph Store's default graph in a SPARQL QUERY

Barry Norton-2

 

I don’t think it should be (in which sense, I think I agree with where you’re coming from), but I’d say it’s odd that the standards made it one.

 

I don’t know if it was I who first pointed out that DEFAULT (together with, and in contrast to, ALL) is a keyword in the Update language, but not the Query language, but I certainly raised it in the Sesame discussions.

 

Similar deal with the unnamed ‘Named Graphs’ – too little guidance in the first place, complete permissiveness in the Update language, little thought in the Graph Store Protocol.

 

Barry

 

 

 

From: Mike Grove [mailto:[hidden email]]
Sent: 01 November 2013 11:25
To: Sesame discussion list
Subject: Re: [Sesame] how to address the Graph Store's default graph in a SPARQL QUERY

 

On Fri, Nov 1, 2013 at 7:00 AM, Barry Norton <[hidden email]> wrote:

 

Well I’m glad to amuse but, seriously, the non-portable solutions to corner cases like the null context (and blank node-‘named’ graphs – thanks, Sesame, for encouraging this) are best avoided by good practice recommendations in my opinion.

 

That's odd that you think the default no-name context of an RDF database is a corner case.

 

 

It’s like the good old days of certain databases allowing spaces in table names when others didn’t. Just avoid it.

 

Barry

 

 

From: Mike Grove [mailto:[hidden email]]
Sent: 01 November 2013 10:50


To: Sesame discussion list
Subject: Re: [Sesame] how to address the Graph Store's default graph in a SPARQL QUERY

 

 

On Fri, Nov 1, 2013 at 6:22 AM, Barry Norton <[hidden email]> wrote:

 

You would deliberately put your data where it’s not fully accessible by the standard?!

 

lol, you're too funny.

 

 

Note that this is even more of an issue with deletion (you can’t identify it with a quad pattern and a triple pattern deletes the statement from all contexts).

 

eh, not really.  That might be what Sesame chooses, but that's not what the standard dictates.  Frankly I think the decision that the active graph, when nothing else is specified, is the entire database is wrong.  It leads to (imo) more problems than it solves, and using a pseudo-graph, say sesame:all, is more clear than having to use one for the default graph.

 

 

Barry

 

 

 

From: Mike Grove [mailto:[hidden email]]
Sent: 31 October 2013 19:26


To: Sesame discussion list
Subject: Re: [Sesame] how to address the Graph Store's default graph in a SPARQL QUERY

 

On Thu, Oct 31, 2013 at 2:40 PM, Barry Norton <[hidden email]> wrote:


I'm with you 100%.

One of my training mantras is: do not put explicit assertions in the [null context].

 

I'll respectively disagree on that point.  It's not clear that gives you any particular advantage.

 

wrt to the OP's question, "FROM DEFAULT" parses with the Sesame SPARQL parser just fine, and, afaict, works as expected.  It seems like a usable workaround to the fact that, by default, Sesame considers the active graph for query evaluation to be the union of the default context & all named graphs.

 

Cheers,

 

Mike

 


Barry


-----Original Message-----
From: David Booth [mailto:[hidden email]]

Sent: 31 October 2013 18:37
To: Sesame discussion list
Subject: Re: [Sesame] how to address the Graph Store's default graph in a SPARQL QUERY

Oh, I see.  Then AFAIK the best work-around is to not use the null context.  Give it an explicit name instead.

David

On 10/31/2013 02:20 PM, Barry Norton wrote:
>
> I believe he wants to address only the null context via SPARQL. Which
> you can't (as I remember).
>
> Barry
>
>
>
> -----Original Message----- From: David Booth [mailto:[hidden email]]
> Sent: 31 October 2013 18:18 To: Sesame discussion list Subject: Re:
> [Sesame] how to address the Graph Store's default graph in a SPARQL
> QUERY
>
> Hi Armando,
>
> I'm not entirely sure that I understand your question, but SPARQL 1.1
> Query has notions of:
>
> - the *default* graph, which will either consist of the merge of named
> graphs that are specified using the FROM syntax; or it will consist of
> somewhat unspecified content that *may* (by default) consist of the
> merge of all of the named graphs in the store (but IIRC this is not
> required by the standard).
> http://www.w3.org/TR/sparql11-query/#unnamedGraph
>
> - the *active* graph, which is the graph against which a particular
> triple pattern will be matched, and may be either the default graph or
> a specifi named graph (if the GRAPH keyword is used).
> http://www.w3.org/TR/sparql11-query/#rdfDataset
>
> Does that help?
>
> David
>
> On 10/31/2013 12:31 PM, Armando Stellato wrote:
>> Dear all,
>>
>> The issue is: through the Sesame2 Repository API, I'm able to
>> retrieve statements from the null context only. I can't do this
>> through SPARQL (not simply at least).
>>
>> I looked for previous posts about this before sending this email:
>>
>> So far, most of the stuff is here:
>>
>> [1] http://www.openrdf.org/forum/mvnforum/viewthread?thread=1518
>>
>> [2] http://www.openrdf.org/issues/browse/SES-848
>>
>> [3] http://www.openrdf.org/issues/browse/SES-849
>>
>> [4] https://openrdf.atlassian.net/browse/SES-850
>>
>> I read about your solution, with sesame:nil, and the proposal you
>> made for standardizing this in SPARQL, with FROM DEFAULT(rejected).
>> Thus, I thought it was an idiosyncrasy between the notion of null
>> context in Sesame2 which maybe is not so close to the notion of
>> default graph in SPARQL.
>>
>> I thus decided to forget about technology, and see at least how the
>> problem is addressed in SPARQL.
>>
>> The SPARQL specifications are rather weird in this:
>>
>> 1) SPARQL 1.1 QUERY specifications define an RDF Dataset's /default
>> graph/ as a defineable graph (scoped to the query) which is either:
>>
>> a) the "RDF Merge" of all named graphs, IFF no FROM/FROM NAMED clause
>> is given
>>
>> b) the dynamic "RDF Merge" of the sole graphs specified in one or
>> more FROM clause
>>
>> 2) SPARQL 1.1 UPDATE specifications define a "Graph Store" 's
>> /default graph/ as the unique "UNNAMED GRAPH" in the store. If no
>> graph is specified in an update, the information is stored in the
>> unnamed graph. A Graph Store's default graph seems to be in a 1-1
>> relationship with the Sesame's null context
>>
>> So, issue is: how to indicate the "Graph Store"'s default graph in a
>> SPARQL QUERY? There seems to be no link among them! SPARQL UPDATE
>> seems to define something (Graph Store's default graph) very close to
>> the null context of Sesame2, while SPARQL QUERY has its own
>> definition of default graph (RDF Dataset's one), but no way to
>> explicitly access the triples in the Graph Store's default graph.
>>
>> Am I missing anything?
>>
>> Cheers,
>>
>> Armando
>>
>> P.S: btw, I tried to use the sesame:nil graph, but no results. I'm
>> using sesame 2.6.8, which was supposed to include it, unless it has
>> been trashed later. Is the namespace the usual one?
>> http://www.openrdf.org/schema/sesame#
>>
>> P.P.S: I know we can obtain this through proper use of !BOUND, MINUS,
>> NOT EXISTS etc... just I'm puzzled by the fact that there is no
>> shorter and more explicit solution (and possibly defined at SPARQL
>> level, not using any store's specific extension). This hinders
>> simplicity of code, other than performance...
>>
>> --------------------------------------------------
>>
>> Ing. Armando Stellato, PhD
>>
>> AI Research Group,
>>
>> Dept. of Enterprise Engineering
>>
>> University of Roma, Tor Vergata
>>
>> Via del Politecnico 1 00133 ROMA (ITALY)
>>
>> tel: <a href="tel:%2B39%2006%207259%207330" target="_blank">+39 06 7259 7330 (office, room A1-14);
>>
>> <a href="tel:%2B39%2006%207259%207332" target="_blank">+39 06 7259 7332 (lab)
>>
>> fax: <a href="tel:%2B39%2006%207259%207460" target="_blank">+39 06 7259 7460
>>
>> e_mail: [hidden email]
>> <mailto:[hidden email]>
>>
>> --------------------------------------------------
>>
>>
>>
>> ---------------------------------------------------------------------
>> -
>>
>>
-------- Android is increasing in popularity, but the open development
>> platform that developers love is also attractive to malware creators.
>> Download this white paper to learn more about secure code signing
>> practices that can help keep Android apps secure.
>> http://pubads.g.doubleclick.net/gampad/clk?id=65839951&iu=/4140/ostg.
>> c
>>
>>
lktrk
>>
>>
>>
>> _______________________________________________ Sesame-general
>> mailing list [hidden email]
>> https://lists.sourceforge.net/lists/listinfo/sesame-general
>>
>
> ----------------------------------------------------------------------
> --------
>
>
Android is increasing in popularity, but the open development platform that developers love is also attractive to malware creators. Download this white paper to learn more about secure code signing practices that can help keep Android apps secure.
> http://pubads.g.doubleclick.net/gampad/clk?id=65839951&iu=/4140/ostg.c
> lktrk
>
>
_______________________________________________
> Sesame-general mailing list [hidden email]
> https://lists.sourceforge.net/lists/listinfo/sesame-general
>
> ----------------------------------------------------------------------
> --------
>
>
Android is increasing in popularity, but the open development platform that
> developers love is also attractive to malware creators. Download this
> white paper to learn more about secure code signing practices that can
> help keep Android apps secure.
> http://pubads.g.doubleclick.net/gampad/clk?id=65839951&iu=/4140/ostg.c
> lktrk
>
>
_______________________________________________
> Sesame-general mailing list [hidden email]
> https://lists.sourceforge.net/lists/listinfo/sesame-general
>
>
>

------------------------------------------------------------------------------
Android is increasing in popularity, but the open development platform that developers love is also attractive to malware creators. Download this white paper to learn more about secure code signing practices that can help keep Android apps secure.
http://pubads.g.doubleclick.net/gampad/clk?id=65839951&iu=/4140/ostg.clktrk
_______________________________________________
Sesame-general mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/sesame-general

------------------------------------------------------------------------------
Android is increasing in popularity, but the open development platform that
developers love is also attractive to malware creators. Download this white
paper to learn more about secure code signing practices that can help keep
Android apps secure.
http://pubads.g.doubleclick.net/gampad/clk?id=65839951&iu=/4140/ostg.clktrk
_______________________________________________
Sesame-general mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/sesame-general

 


------------------------------------------------------------------------------
Android is increasing in popularity, but the open development platform that
developers love is also attractive to malware creators. Download this white
paper to learn more about secure code signing practices that can help keep
Android apps secure.
http://pubads.g.doubleclick.net/gampad/clk?id=65839951&iu=/4140/ostg.clktrk
_______________________________________________
Sesame-general mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/sesame-general

 


------------------------------------------------------------------------------
Android is increasing in popularity, but the open development platform that
developers love is also attractive to malware creators. Download this white
paper to learn more about secure code signing practices that can help keep
Android apps secure.
http://pubads.g.doubleclick.net/gampad/clk?id=65839951&iu=/4140/ostg.clktrk
_______________________________________________
Sesame-general mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/sesame-general

 


------------------------------------------------------------------------------
Android is increasing in popularity, but the open development platform that
developers love is also attractive to malware creators. Download this white
paper to learn more about secure code signing practices that can help keep
Android apps secure.
http://pubads.g.doubleclick.net/gampad/clk?id=65839951&iu=/4140/ostg.clktrk
_______________________________________________
Sesame-general mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/sesame-general
Reply | Threaded
Open this post in threaded view
|

Re: how to address the Graph Store's default graph in a SPARQL QUERY

Mike Grove-2
On Fri, Nov 1, 2013 at 7:32 AM, Barry Norton <[hidden email]> wrote:

 

I don’t think it should be (in which sense, I think I agree with where you’re coming from), but I’d say it’s odd that the standards made it one.


I think it's odd that the standard does not actually define that the default active graph is for SPARQL.  Sesame uses the entire database, other systems use only the default context.  Nothing like 100% compliant SPARQL engines giving different answers to the same queries over the same data.  +1 for interop.
 

 

I don’t know if it was I who first pointed out that DEFAULT (together with, and in contrast to, ALL) is a keyword in the Update language, but not the Query language, but I certainly raised it in the Sesame discussions.

 

Similar deal with the unnamed ‘Named Graphs’ – too little guidance in the first place, complete permissiveness in the Update language, little thought in the Graph Store Protocol.


Oh god, don't get me started on the Graph Store Protocol.


 

Barry

 

 

 

From: Mike Grove [mailto:[hidden email]]
Sent: 01 November 2013 11:25


To: Sesame discussion list
Subject: Re: [Sesame] how to address the Graph Store's default graph in a SPARQL QUERY

 

On Fri, Nov 1, 2013 at 7:00 AM, Barry Norton <[hidden email]> wrote:

 

Well I’m glad to amuse but, seriously, the non-portable solutions to corner cases like the null context (and blank node-‘named’ graphs – thanks, Sesame, for encouraging this) are best avoided by good practice recommendations in my opinion.

 

That's odd that you think the default no-name context of an RDF database is a corner case.

 

 

It’s like the good old days of certain databases allowing spaces in table names when others didn’t. Just avoid it.

 

Barry

 

 

From: Mike Grove [mailto:[hidden email]]
Sent: 01 November 2013 10:50


To: Sesame discussion list
Subject: Re: [Sesame] how to address the Graph Store's default graph in a SPARQL QUERY

 

 

On Fri, Nov 1, 2013 at 6:22 AM, Barry Norton <[hidden email]> wrote:

 

You would deliberately put your data where it’s not fully accessible by the standard?!

 

lol, you're too funny.

 

 

Note that this is even more of an issue with deletion (you can’t identify it with a quad pattern and a triple pattern deletes the statement from all contexts).

 

eh, not really.  That might be what Sesame chooses, but that's not what the standard dictates.  Frankly I think the decision that the active graph, when nothing else is specified, is the entire database is wrong.  It leads to (imo) more problems than it solves, and using a pseudo-graph, say sesame:all, is more clear than having to use one for the default graph.

 

 

Barry

 

 

 

From: Mike Grove [mailto:[hidden email]]
Sent: 31 October 2013 19:26


To: Sesame discussion list
Subject: Re: [Sesame] how to address the Graph Store's default graph in a SPARQL QUERY

 

On Thu, Oct 31, 2013 at 2:40 PM, Barry Norton <[hidden email]> wrote:


I'm with you 100%.

One of my training mantras is: do not put explicit assertions in the [null context].

 

I'll respectively disagree on that point.  It's not clear that gives you any particular advantage.

 

wrt to the OP's question, "FROM DEFAULT" parses with the Sesame SPARQL parser just fine, and, afaict, works as expected.  It seems like a usable workaround to the fact that, by default, Sesame considers the active graph for query evaluation to be the union of the default context & all named graphs.

 

Cheers,

 

Mike

 


Barry


-----Original Message-----
From: David Booth [mailto:[hidden email]]

Sent: 31 October 2013 18:37
To: Sesame discussion list
Subject: Re: [Sesame] how to address the Graph Store's default graph in a SPARQL QUERY

Oh, I see.  Then AFAIK the best work-around is to not use the null context.  Give it an explicit name instead.

David

On 10/31/2013 02:20 PM, Barry Norton wrote:
>
> I believe he wants to address only the null context via SPARQL. Which
> you can't (as I remember).
>
> Barry
>
>
>
> -----Original Message----- From: David Booth [mailto:[hidden email]]
> Sent: 31 October 2013 18:18 To: Sesame discussion list Subject: Re:
> [Sesame] how to address the Graph Store's default graph in a SPARQL
> QUERY
>
> Hi Armando,
>
> I'm not entirely sure that I understand your question, but SPARQL 1.1
> Query has notions of:
>
> - the *default* graph, which will either consist of the merge of named
> graphs that are specified using the FROM syntax; or it will consist of
> somewhat unspecified content that *may* (by default) consist of the
> merge of all of the named graphs in the store (but IIRC this is not
> required by the standard).
> http://www.w3.org/TR/sparql11-query/#unnamedGraph
>
> - the *active* graph, which is the graph against which a particular
> triple pattern will be matched, and may be either the default graph or
> a specifi named graph (if the GRAPH keyword is used).
> http://www.w3.org/TR/sparql11-query/#rdfDataset
>
> Does that help?
>
> David
>
> On 10/31/2013 12:31 PM, Armando Stellato wrote:
>> Dear all,
>>
>> The issue is: through the Sesame2 Repository API, I'm able to
>> retrieve statements from the null context only. I can't do this
>> through SPARQL (not simply at least).
>>
>> I looked for previous posts about this before sending this email:
>>
>> So far, most of the stuff is here:
>>
>> [1] http://www.openrdf.org/forum/mvnforum/viewthread?thread=1518
>>
>> [2] http://www.openrdf.org/issues/browse/SES-848
>>
>> [3] http://www.openrdf.org/issues/browse/SES-849
>>
>> [4] https://openrdf.atlassian.net/browse/SES-850
>>
>> I read about your solution, with sesame:nil, and the proposal you
>> made for standardizing this in SPARQL, with FROM DEFAULT(rejected).
>> Thus, I thought it was an idiosyncrasy between the notion of null
>> context in Sesame2 which maybe is not so close to the notion of
>> default graph in SPARQL.
>>
>> I thus decided to forget about technology, and see at least how the
>> problem is addressed in SPARQL.
>>
>> The SPARQL specifications are rather weird in this:
>>
>> 1) SPARQL 1.1 QUERY specifications define an RDF Dataset's /default
>> graph/ as a defineable graph (scoped to the query) which is either:
>>
>> a) the "RDF Merge" of all named graphs, IFF no FROM/FROM NAMED clause
>> is given
>>
>> b) the dynamic "RDF Merge" of the sole graphs specified in one or
>> more FROM clause
>>
>> 2) SPARQL 1.1 UPDATE specifications define a "Graph Store" 's
>> /default graph/ as the unique "UNNAMED GRAPH" in the store. If no
>> graph is specified in an update, the information is stored in the
>> unnamed graph. A Graph Store's default graph seems to be in a 1-1
>> relationship with the Sesame's null context
>>
>> So, issue is: how to indicate the "Graph Store"'s default graph in a
>> SPARQL QUERY? There seems to be no link among them! SPARQL UPDATE
>> seems to define something (Graph Store's default graph) very close to
>> the null context of Sesame2, while SPARQL QUERY has its own
>> definition of default graph (RDF Dataset's one), but no way to
>> explicitly access the triples in the Graph Store's default graph.
>>
>> Am I missing anything?
>>
>> Cheers,
>>
>> Armando
>>
>> P.S: btw, I tried to use the sesame:nil graph, but no results. I'm
>> using sesame 2.6.8, which was supposed to include it, unless it has
>> been trashed later. Is the namespace the usual one?
>> http://www.openrdf.org/schema/sesame#
>>
>> P.P.S: I know we can obtain this through proper use of !BOUND, MINUS,
>> NOT EXISTS etc... just I'm puzzled by the fact that there is no
>> shorter and more explicit solution (and possibly defined at SPARQL
>> level, not using any store's specific extension). This hinders
>> simplicity of code, other than performance...
>>
>> --------------------------------------------------
>>
>> Ing. Armando Stellato, PhD
>>
>> AI Research Group,
>>
>> Dept. of Enterprise Engineering
>>
>> University of Roma, Tor Vergata
>>
>> Via del Politecnico 1 00133 ROMA (ITALY)
>>
>> tel: <a href="tel:%2B39%2006%207259%207330" target="_blank">+39 06 7259 7330 (office, room A1-14);
>>
>> <a href="tel:%2B39%2006%207259%207332" target="_blank">+39 06 7259 7332 (lab)
>>
>> fax: <a href="tel:%2B39%2006%207259%207460" target="_blank">+39 06 7259 7460
>>
>> e_mail: [hidden email]
>> <mailto:[hidden email]>
>>
>> --------------------------------------------------
>>
>>
>>
>> ---------------------------------------------------------------------
>> -
>>
>>
-------- Android is increasing in popularity, but the open development
>> platform that developers love is also attractive to malware creators.
>> Download this white paper to learn more about secure code signing
>> practices that can help keep Android apps secure.
>> http://pubads.g.doubleclick.net/gampad/clk?id=65839951&iu=/4140/ostg.
>> c
>>
>>
lktrk
>>
>>
>>
>> _______________________________________________ Sesame-general
>> mailing list [hidden email]
>> https://lists.sourceforge.net/lists/listinfo/sesame-general
>>
>
> ----------------------------------------------------------------------
> --------
>
>
Android is increasing in popularity, but the open development platform that developers love is also attractive to malware creators. Download this white paper to learn more about secure code signing practices that can help keep Android apps secure.
> http://pubads.g.doubleclick.net/gampad/clk?id=65839951&iu=/4140/ostg.c
> lktrk
>
>
_______________________________________________
> Sesame-general mailing list [hidden email]
> https://lists.sourceforge.net/lists/listinfo/sesame-general
>
> ----------------------------------------------------------------------
> --------
>
>
Android is increasing in popularity, but the open development platform that
> developers love is also attractive to malware creators. Download this
> white paper to learn more about secure code signing practices that can
> help keep Android apps secure.
> http://pubads.g.doubleclick.net/gampad/clk?id=65839951&iu=/4140/ostg.c
> lktrk
>
>
_______________________________________________
> Sesame-general mailing list [hidden email]
> https://lists.sourceforge.net/lists/listinfo/sesame-general
>
>
>

------------------------------------------------------------------------------
Android is increasing in popularity, but the open development platform that developers love is also attractive to malware creators. Download this white paper to learn more about secure code signing practices that can help keep Android apps secure.
http://pubads.g.doubleclick.net/gampad/clk?id=65839951&iu=/4140/ostg.clktrk
_______________________________________________
Sesame-general mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/sesame-general

------------------------------------------------------------------------------
Android is increasing in popularity, but the open development platform that
developers love is also attractive to malware creators. Download this white
paper to learn more about secure code signing practices that can help keep
Android apps secure.
http://pubads.g.doubleclick.net/gampad/clk?id=65839951&iu=/4140/ostg.clktrk
_______________________________________________
Sesame-general mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/sesame-general

 


------------------------------------------------------------------------------
Android is increasing in popularity, but the open development platform that
developers love is also attractive to malware creators. Download this white
paper to learn more about secure code signing practices that can help keep
Android apps secure.
http://pubads.g.doubleclick.net/gampad/clk?id=65839951&iu=/4140/ostg.clktrk
_______________________________________________
Sesame-general mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/sesame-general

 


------------------------------------------------------------------------------
Android is increasing in popularity, but the open development platform that
developers love is also attractive to malware creators. Download this white
paper to learn more about secure code signing practices that can help keep
Android apps secure.
http://pubads.g.doubleclick.net/gampad/clk?id=65839951&iu=/4140/ostg.clktrk
_______________________________________________
Sesame-general mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/sesame-general

 


------------------------------------------------------------------------------
Android is increasing in popularity, but the open development platform that
developers love is also attractive to malware creators. Download this white
paper to learn more about secure code signing practices that can help keep
Android apps secure.
http://pubads.g.doubleclick.net/gampad/clk?id=65839951&iu=/4140/ostg.clktrk
_______________________________________________
Sesame-general mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/sesame-general



------------------------------------------------------------------------------
Android is increasing in popularity, but the open development platform that
developers love is also attractive to malware creators. Download this white
paper to learn more about secure code signing practices that can help keep
Android apps secure.
http://pubads.g.doubleclick.net/gampad/clk?id=65839951&iu=/4140/ostg.clktrk
_______________________________________________
Sesame-general mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/sesame-general
Reply | Threaded
Open this post in threaded view
|

Re: how to address the Graph Store's default graph in a SPARQL QUERY

Armando Stellato

Dear all,

 

by first, thanks for all the answers. My first result is that, yes, you are confirming me that, currently (and dunno about the future :-) ) the null context is not directly accessible through SPARQL. All the links I followed (reported in my original email) ended up 6 months ago, with no further news on the thing, so good to get some explicit confirmation.

 

For what concerns the discussion which has followed, well, depending on the context (of discourse, not the sesame one :-D ), I may (only partially) agree with one, or fully agree with the other.

 

This is not the first time I hear the “ban the null context from your life” mantra. In the specific, about (*the current situation of*) sesame, using a named graph instead of the null graph is one of the options I was considering, though still not really convinced, as I see many drawbacks (at least in my application scenario)

…but it’s when I think about “how things could be”, and when I move away from  Sesame and think about SPARQL in general, that I fully agree with Mike.

 

By first (and replying also to David), yes, I got those definitions already, but you were missing one in your reply, which I mentioned in my email, and which is contained in the SPARQL UPDATE specifications: http://www.w3.org/TR/sparql11-update/#graphStore

which tells us:

“a Graph Store contains one (unnamed) slot holding a default graph and zero or more named slots holding named graphs. Operations may specify graphs to be modified, or they may rely on a default graph for that operation. Unless overridden (for instance, by the SPARQL protocol), the unnamed graph for the store will be the default graph for any operations on that store”

 

So, in short: the default graph in a QUERY does not correspond a-priori to any real graph in the store, and is just (scoped to the query) dynamically obtained by the RDF MERGE of those graphs explicitly mentioned through FROM, or (in case of no FROM/FROM NAMED clause) of all the graphs in the store.

But in the UPDATE specs, we have an explicit mention of this “Graph Store’s default graph”, which is totally a different thing; it is a real graph, which each store should implement, and it is roughly in 1-1 rel with the sesame null context.

 

Ok, so, even by taking no position on the “null context: I like it or not” diatribe, I’m really puzzled about the coherency of the SPARQL specs: just relying on the specs, a SPARQL UPDATE not scoped to any graph, stores triples in this fantastic UNNAMED graph (the Graph Store default graph), but then, there is no way of mentioning it explicitly in a QUERY, if not through this computational dementia [1].

 

Now, what I wrote before is JUST about incoherency in the specs. Then, if I have to take a position…well…for sake of interoperability, I would like to be able to address (with a standard name, or a no name, it doesn’t matter) the explicit content which has been added through a non-graph-scoped SPARQL UPDATE.

 

I don’t know the whys of the FROM DEFAULT rejection from the WG (maybe Jeen can shed some light on this, and I would be really interested in knowing more about that). In my view, again, for sake of interoperability, and at least for coherency of the specs, that would be really needed (obviously, standardized). “FROM sesame:nil” is a nice extension, but unfortunately, as I’m working in a triplestore-technology-agnostic case, I can’t consider using it.

 

Many thanks again,

 

Armando

 

[1] a query for retrieving the Graph Store’s default graph. How to waste computational effort for retrieving what cannot be explicitly mentioned. This is a diff like: (EVERYTHING \ (EVERYTHING \ default) ) = default

select ?s ?p ?o ?g
where

?s ?p ?o .

OPTIONAL { 
GRAPH ?g

{ ?s ?p ?o . }

}
FILTER ( !bound(?g) )
}

(or, in sparql 1.1, by using FILTER NOT EXISTS )

 

 

 

From: Mike Grove [mailto:[hidden email]]
Sent: Friday, November 1, 2013 12:44 PM
To: Sesame discussion list
Subject: Re: [Sesame] how to address the Graph Store's default graph in a SPARQL QUERY

 

On Fri, Nov 1, 2013 at 7:32 AM, Barry Norton <[hidden email]> wrote:

 

I don’t think it should be (in which sense, I think I agree with where you’re coming from), but I’d say it’s odd that the standards made it one.

 

I think it's odd that the standard does not actually define that the default active graph is for SPARQL.  Sesame uses the entire database, other systems use only the default context.  Nothing like 100% compliant SPARQL engines giving different answers to the same queries over the same data.  +1 for interop.

 

 

I don’t know if it was I who first pointed out that DEFAULT (together with, and in contrast to, ALL) is a keyword in the Update language, but not the Query language, but I certainly raised it in the Sesame discussions.

 

Similar deal with the unnamed ‘Named Graphs’ – too little guidance in the first place, complete permissiveness in the Update language, little thought in the Graph Store Protocol.

 

Oh god, don't get me started on the Graph Store Protocol.

 

 

 

Barry

 

 

 

From: Mike Grove [mailto:[hidden email]]
Sent: 01 November 2013 11:25


To: Sesame discussion list
Subject: Re: [Sesame] how to address the Graph Store's default graph in a SPARQL QUERY

 

On Fri, Nov 1, 2013 at 7:00 AM, Barry Norton <[hidden email]> wrote:

 

Well I’m glad to amuse but, seriously, the non-portable solutions to corner cases like the null context (and blank node-‘named’ graphs – thanks, Sesame, for encouraging this) are best avoided by good practice recommendations in my opinion.

 

That's odd that you think the default no-name context of an RDF database is a corner case.

 

 

It’s like the good old days of certain databases allowing spaces in table names when others didn’t. Just avoid it.

 

Barry

 

 

From: Mike Grove [mailto:[hidden email]]
Sent: 01 November 2013 10:50


To: Sesame discussion list
Subject: Re: [Sesame] how to address the Graph Store's default graph in a SPARQL QUERY

 

 

On Fri, Nov 1, 2013 at 6:22 AM, Barry Norton <[hidden email]> wrote:

 

You would deliberately put your data where it’s not fully accessible by the standard?!

 

lol, you're too funny.

 

 

Note that this is even more of an issue with deletion (you can’t identify it with a quad pattern and a triple pattern deletes the statement from all contexts).

 

eh, not really.  That might be what Sesame chooses, but that's not what the standard dictates.  Frankly I think the decision that the active graph, when nothing else is specified, is the entire database is wrong.  It leads to (imo) more problems than it solves, and using a pseudo-graph, say sesame:all, is more clear than having to use one for the default graph.

 

 

Barry

 

 

 

From: Mike Grove [mailto:[hidden email]]
Sent: 31 October 2013 19:26


To: Sesame discussion list
Subject: Re: [Sesame] how to address the Graph Store's default graph in a SPARQL QUERY

 

On Thu, Oct 31, 2013 at 2:40 PM, Barry Norton <[hidden email]> wrote:


I'm with you 100%.

One of my training mantras is: do not put explicit assertions in the [null context].

 

I'll respectively disagree on that point.  It's not clear that gives you any particular advantage.

 

wrt to the OP's question, "FROM DEFAULT" parses with the Sesame SPARQL parser just fine, and, afaict, works as expected.  It seems like a usable workaround to the fact that, by default, Sesame considers the active graph for query evaluation to be the union of the default context & all named graphs.

 

Cheers,

 

Mike

 


Barry


-----Original Message-----
From: David Booth [mailto:[hidden email]]

Sent: 31 October 2013 18:37
To: Sesame discussion list
Subject: Re: [Sesame] how to address the Graph Store's default graph in a SPARQL QUERY

Oh, I see.  Then AFAIK the best work-around is to not use the null context.  Give it an explicit name instead.

David

On 10/31/2013 02:20 PM, Barry Norton wrote:


>
> I believe he wants to address only the null context via SPARQL. Which
> you can't (as I remember).
>
> Barry
>
>
>
> -----Original Message----- From: David Booth [mailto:[hidden email]]
> Sent: 31 October 2013 18:18 To: Sesame discussion list Subject: Re:
> [Sesame] how to address the Graph Store's default graph in a SPARQL
> QUERY
>
> Hi Armando,
>
> I'm not entirely sure that I understand your question, but SPARQL 1.1
> Query has notions of:
>
> - the *default* graph, which will either consist of the merge of named
> graphs that are specified using the FROM syntax; or it will consist of
> somewhat unspecified content that *may* (by default) consist of the
> merge of all of the named graphs in the store (but IIRC this is not
> required by the standard).
> http://www.w3.org/TR/sparql11-query/#unnamedGraph
>
> - the *active* graph, which is the graph against which a particular
> triple pattern will be matched, and may be either the default graph or
> a specifi named graph (if the GRAPH keyword is used).
> http://www.w3.org/TR/sparql11-query/#rdfDataset
>
> Does that help?
>
> David
>
> On 10/31/2013 12:31 PM, Armando Stellato wrote:
>> Dear all,
>>
>> The issue is: through the Sesame2 Repository API, I'm able to
>> retrieve statements from the null context only. I can't do this
>> through SPARQL (not simply at least).
>>
>> I looked for previous posts about this before sending this email:
>>
>> So far, most of the stuff is here:
>>
>> [1] http://www.openrdf.org/forum/mvnforum/viewthread?thread=1518
>>
>> [2] http://www.openrdf.org/issues/browse/SES-848
>>
>> [3] http://www.openrdf.org/issues/browse/SES-849
>>
>> [4] https://openrdf.atlassian.net/browse/SES-850
>>
>> I read about your solution, with sesame:nil, and the proposal you
>> made for standardizing this in SPARQL, with FROM DEFAULT(rejected).
>> Thus, I thought it was an idiosyncrasy between the notion of null
>> context in Sesame2 which maybe is not so close to the notion of
>> default graph in SPARQL.
>>
>> I thus decided to forget about technology, and see at least how the
>> problem is addressed in SPARQL.
>>
>> The SPARQL specifications are rather weird in this:
>>
>> 1) SPARQL 1.1 QUERY specifications define an RDF Dataset's /default
>> graph/ as a defineable graph (scoped to the query) which is either:
>>
>> a) the "RDF Merge" of all named graphs, IFF no FROM/FROM NAMED clause
>> is given
>>
>> b) the dynamic "RDF Merge" of the sole graphs specified in one or
>> more FROM clause
>>
>> 2) SPARQL 1.1 UPDATE specifications define a "Graph Store" 's
>> /default graph/ as the unique "UNNAMED GRAPH" in the store. If no
>> graph is specified in an update, the information is stored in the
>> unnamed graph. A Graph Store's default graph seems to be in a 1-1
>> relationship with the Sesame's null context
>>
>> So, issue is: how to indicate the "Graph Store"'s default graph in a
>> SPARQL QUERY? There seems to be no link among them! SPARQL UPDATE
>> seems to define something (Graph Store's default graph) very close to
>> the null context of Sesame2, while SPARQL QUERY has its own
>> definition of default graph (RDF Dataset's one), but no way to
>> explicitly access the triples in the Graph Store's default graph.
>>
>> Am I missing anything?
>>
>> Cheers,
>>
>> Armando
>>
>> P.S: btw, I tried to use the sesame:nil graph, but no results. I'm
>> using sesame 2.6.8, which was supposed to include it, unless it has
>> been trashed later. Is the namespace the usual one?
>> http://www.openrdf.org/schema/sesame#
>>
>> P.P.S: I know we can obtain this through proper use of !BOUND, MINUS,
>> NOT EXISTS etc... just I'm puzzled by the fact that there is no
>> shorter and more explicit solution (and possibly defined at SPARQL
>> level, not using any store's specific extension). This hinders
>> simplicity of code, other than performance...
>>
>> --------------------------------------------------
>>
>> Ing. Armando Stellato, PhD
>>
>> AI Research Group,
>>
>> Dept. of Enterprise Engineering
>>
>> University of Roma, Tor Vergata
>>
>> Via del Politecnico 1 00133 ROMA (ITALY)
>>
>> tel: <a href="tel:%2B39%2006%207259%207330" target="_blank">+39 06 7259 7330 (office, room A1-14);
>>
>> <a href="tel:%2B39%2006%207259%207332" target="_blank">+39 06 7259 7332 (lab)
>>
>> fax: <a href="tel:%2B39%2006%207259%207460" target="_blank">+39 06 7259 7460
>>
>> e_mail: [hidden email]
>> <mailto:[hidden email]>
>>
>> --------------------------------------------------
>>
>>
>>
>> ---------------------------------------------------------------------
>> -
>>
>>
-------- Android is increasing in popularity, but the open development
>> platform that developers love is also attractive to malware creators.
>> Download this white paper to learn more about secure code signing
>> practices that can help keep Android apps secure.
>> http://pubads.g.doubleclick.net/gampad/clk?id=65839951&iu=/4140/ostg.
>> c
>>
>>
lktrk

>>
>>
>>
>> _______________________________________________ Sesame-general
>> mailing list [hidden email]
>> https://lists.sourceforge.net/lists/listinfo/sesame-general
>>
>
> ----------------------------------------------------------------------
> --------
>
>
Android is increasing in popularity, but the open development platform that developers love is also attractive to malware creators. Download this white paper to learn more about secure code signing practices that can help keep Android apps secure.
> http://pubads.g.doubleclick.net/gampad/clk?id=65839951&iu=/4140/ostg.c
> lktrk
>
>
_______________________________________________
> Sesame-general mailing list [hidden email]
> https://lists.sourceforge.net/lists/listinfo/sesame-general
>
> ----------------------------------------------------------------------
> --------
>
>
Android is increasing in popularity, but the open development platform that
> developers love is also attractive to malware creators. Download this
> white paper to learn more about secure code signing practices that can
> help keep Android apps secure.
> http://pubads.g.doubleclick.net/gampad/clk?id=65839951&iu=/4140/ostg.c
> lktrk
>
>
_______________________________________________
> Sesame-general mailing list [hidden email]
> https://lists.sourceforge.net/lists/listinfo/sesame-general
>
>
>

------------------------------------------------------------------------------
Android is increasing in popularity, but the open development platform that developers love is also attractive to malware creators. Download this white paper to learn more about secure code signing practices that can help keep Android apps secure.
http://pubads.g.doubleclick.net/gampad/clk?id=65839951&iu=/4140/ostg.clktrk
_______________________________________________
Sesame-general mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/sesame-general

------------------------------------------------------------------------------
Android is increasing in popularity, but the open development platform that
developers love is also attractive to malware creators. Download this white
paper to learn more about secure code signing practices that can help keep
Android apps secure.
http://pubads.g.doubleclick.net/gampad/clk?id=65839951&iu=/4140/ostg.clktrk
_______________________________________________
Sesame-general mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/sesame-general

 


------------------------------------------------------------------------------
Android is increasing in popularity, but the open development platform that
developers love is also attractive to malware creators. Download this white
paper to learn more about secure code signing practices that can help keep
Android apps secure.
http://pubads.g.doubleclick.net/gampad/clk?id=65839951&iu=/4140/ostg.clktrk
_______________________________________________
Sesame-general mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/sesame-general

 


------------------------------------------------------------------------------
Android is increasing in popularity, but the open development platform that
developers love is also attractive to malware creators. Download this white
paper to learn more about secure code signing practices that can help keep
Android apps secure.
http://pubads.g.doubleclick.net/gampad/clk?id=65839951&iu=/4140/ostg.clktrk
_______________________________________________
Sesame-general mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/sesame-general

 


------------------------------------------------------------------------------
Android is increasing in popularity, but the open development platform that
developers love is also attractive to malware creators. Download this white
paper to learn more about secure code signing practices that can help keep
Android apps secure.
http://pubads.g.doubleclick.net/gampad/clk?id=65839951&iu=/4140/ostg.clktrk
_______________________________________________
Sesame-general mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/sesame-general

 


------------------------------------------------------------------------------
Android is increasing in popularity, but the open development platform that
developers love is also attractive to malware creators. Download this white
paper to learn more about secure code signing practices that can help keep
Android apps secure.
http://pubads.g.doubleclick.net/gampad/clk?id=65839951&iu=/4140/ostg.clktrk
_______________________________________________
Sesame-general mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/sesame-general
Reply | Threaded
Open this post in threaded view
|

Re: how to address the Graph Store's default graph in a SPARQL QUERY

Jeen Broekstra
In reply to this post by Barry Norton-2
On 2/11/13 12:00 am, Barry Norton wrote:
> Well I’m glad to amuse but, seriously, the non-portable solutions to
> corner cases like the null context (and blank node-‘named’ graphs –
> thanks, Sesame, for encouraging this) are best avoided by good practice
> recommendations in my opinion.

FwIW Sesame's context mechanism predates the notion of named graphs.
Hardly our fault the standard didn't conform with our idea :)

As for changing the interpretation of the default graph to *not* be the
entire repository, we discussed that quite recently as I was actually in
favor of it. Turns out that most users were against us changing this though.

  Instead, we have made it a configurable option.

Jeen


------------------------------------------------------------------------------
Android is increasing in popularity, but the open development platform that
developers love is also attractive to malware creators. Download this white
paper to learn more about secure code signing practices that can help keep
Android apps secure.
http://pubads.g.doubleclick.net/gampad/clk?id=65839951&iu=/4140/ostg.clktrk
_______________________________________________
Sesame-general mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/sesame-general