How do sparql update (insert/delete)?

[DJ]

Dear all,

How to use sparql-update in TBCME/FE? I can't find the option to apply
a sparql update (insert/delete) on a KB (Knowledge Base).
There is also little info about HOW to do it (or maybe there but I
can't find it?).

Thank you very much.
DJ

[Holger Knublauch]

Hi DJ,

SPARQL Update is part of TopBraid's general SPARQL support. Just enter the UPDATE request into the SPARQL view and press the run button.

Holger

> --
> You received this message because you are subscribed to the Google
> Group "TopBraid Suite Users", the topics of which include TopBraid Composer,
> TopBraid Live, TopBraid Ensemble, SPARQLMotion and SPIN.
> To post to this group, send email to
> topbrai...@googlegroups.com
> To unsubscribe from this group, send email to
> topbraid-user...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/topbraid-users?hl=en

[Jan Polowinski]

I'm trying to construct a graph depending on

a) an existing graph +
b) the already created part of the new graph.

Does the WHERE part of an INSERT statement only consider the graph before starting the INSERT? Or should it consider the newly created triples already? Here is what I tried:

# construct a GO for all subjects in knows-relations
INSERT {
_:0 a :GO .
_:0 :represents ?who .
}
WHERE {
?who :knows ?whom .
NOT EXISTS {
?someGO :represents ?who .
} .
}

Although using NOT EXISTS, in the first run, I create more blank nodes than I want to. In additional runs then everything works as expected.

I'm happy for any hints. Do I expect too much of SPARQL here? Or am I only missing some setting? I could not explicitly find something about this issue in the SPARQL 1.1 Update specification. Does anybody know an alternative to achieve that the newly created triples are immediately considered in the WHERE clause?

Jan

[Scott Henninger]

Jan, the WHERE clause of all SPARQL queries is applied to the current data graph.  CONSTRUCT, INSERT, DELETE, etc. are applied to the results of the WHERE clause.  Therefore the WHERE clause cannot recursively consider any INSERTs/DELETEs to the data.

To query the result of inserting some data, you will need to apply two queries: the insert, then the query. So it will be something like the following (I wasn't really able to understand the intent of your query):

INSERT
{ #using GRAPH to explicitly state where the data is inserted in highly recommended

   _:0 a :GO .
   _:0 :represents ?who .
}
WHERE
{  ?who :knows ?whom .
}

...then you can query the resulting graph:

SELECT ?who ?whom

WHERE
{    ?who :knows ?whom .
    NOT EXISTS
    {    ?someGO :represents ?who .
    } .
}

...which is a strange query because it cannot match anything after the INSERT.

--
Scott Henninger
Sr, Product & Support Engineer, TopQuadrant, Inc.,
tel: 402-429-3751 / fax: 703 991-8192 / main: 703 299-9330
Training:
   Semantic Technology Training and Intro to TopBraid - Sept. 12-15, 2011, Washington, DC
   TopBraid Advanced Products Training - Sept. 26-29, 2011, Washington, DC
TQ Blog: Voyages of the Semantic Enterprise

[Jan Polowinski]

Hello Scott, thank you for the very quick response.

Jan, the WHERE clause of all SPARQL queries is applied to the current data graph.  CONSTRUCT, INSERT, DELETE, etc. are applied to the results of the WHERE clause.  Therefore the WHERE clause cannot recursively consider any INSERTs/DELETEs to the data.

To query the result of inserting some data, you will need to apply two queries: the insert, then the query. So it will be something like the following

So I will have to create two queries - one for inserting the triples and then a second to remove the "duplicates" that are created without the NOT EXISTS. 

In the example, the goal is to create the "represents" triple exactly once, even when a resource is involved in multiple knows relations.

So for the (likely) case ...

Peter knows Tom

Peter knows Mary

I'd like to create ...

_:go1 represents Peter

but not ...

_:go1 represents Peter

_:go2 represents Peter

I think a second query deleting the duplicates will do the job then. Although I don't quite like the idea of creating triples just to delete them in the next step.

(I wasn't really able to understand the intent of your query):

(Go stands for graphic object here. A parallel graph of graphic objects shall be constructed for the source data.)

Thank you again for clarifying this though it was only a SPARQL-question, as it seems.

Jan

--
You received this message because you are subscribed to the Google
Group "TopBraid Suite Users", the topics of which include TopBraid Composer,
TopBraid Live, TopBraid Ensemble, SPARQLMotion and SPIN.
To post to this group, send email to
topbrai...@googlegroups.com
To unsubscribe from this group, send email to
topbraid-user...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/topbraid-users?hl=en

--

Dipl. Medien-Inf. Jan Polowinski

Research Assistant

Technische Universität Dresden
Department of Computer Science

Software- and Multimedia-Technology

01062 Dresden

Phone: +49 351 463 38608
Mobil: +49 176 80158257
E-Mail: jan.pol...@tu-dresden.de

[Scott Henninger]

Jan, not clear why you might need bnodes, but one solution to your problem is to create some unique URI.  The INSERT will then be applied for each match, but the same triple is generated.  hence only one triple is generated for each ?who binding.  For example:

INSERT
{  ?uri example:represents ?who .
}
WHERE
{  ?who example:knows ?whom .
   BIND (smf:buildUniqueURI(":something") AS ?uri)
}

-- Scott

[Holger Knublauch]

This sounds like a use case for magic properties aka property functions. I may misunderstand the details but you seem to first create some auxiliary triples so that you can query them later. Have a look at

http://composing-the-semantic-web.blogspot.com/2009/11/magic-properties-with-spin.html

to see whether these magic properties - that are created on demand at query time - make writing your queries easier.

Holger