This is a public chat log generated from the #semsol IRC channel.
11:33:17
do you plan to integrate "typed node elements" into the rdf serializer?
11:33:44
you can find an example of it under http://www.w3.org/TR/rdf-syntax-grammar
11:33:51
2.13 Typed Node Elements
11:34:16
this would be much more human readable than the rdf:Description tags
11:51:37
not planned for now
11:53:35
wouldn't be hard to tweak, but it's not really a priority
11:59:48
I've put them on my todo list for the release candidate
12:08:39
yes your right this isn't too important for now, but it would be a nice feature
12:09:18
did you read the mail in the mailing list about this bug with GRAPH and OPTION?
12:16:08
no, not yet
16:17:56
if I delete a triple with "DELETE ..." it is not removed in the mysql database
16:18:42
do I understand it right that every 50th LOAD or DELETE query the function optimizeTables() does this for me?
16:19:18
yes
16:19:41
the DELETE only removes the graph2triple relation, IIRC
16:22:26
ok great
16:27:36
I'm testing this right at the moment
16:27:54
but unfortunately the s2val table doesn't get cleared
16:28:27
the other tables also
16:28:49
yes, the val-tables remember values and ids
16:29:27
but isn't this a problem when the store is growing bigger and bigger?
16:29:50
is it for you?
16:30:13
I'm not sure, but maybe in the future
16:30:27
then let's talk in the future ;)
16:30:28
I want to load and delete lots of foaf profiles
16:30:58
should this become a problem, I'll add a cleanup method
16:31:13
but what is the benefit from rembering those values?
16:31:47
better performance
16:32:04
k
16:32:10
thx
16:33:07
you can use DUMP + LOAD to create a clean copy of a store
16:33:26
ok thank you, I'll try that
16:34:34
it's mostly the o2val tables that can bloat up
16:35:25
yes absolutely
16:35:40
e.g. when you use a store to manage sessions, where each request sets a new "last_contact" or somesuch
16:36:22
if you run into issues, ping me and I'll extend the cleanTableReferences method
16:36:48
I'm writing a foaf browser, everytime the user want so see a profile it is LOADED, so over the time this could really bloat up the database
16:36:54
ok
16:37:11
I'm still in development, so we'll wait ;)
16:37:17
;)
16:37:57
I see
18:48:34
hey bengee.
18:48:43
heya
18:49:19
wondering if there's a facility to rename a named graph within a store... I don't think SPARUL supports this.
18:49:42
in ARC of course.
18:53:14
I can probably just do this by deleting and re-inserting graphs under a new name, but there must be a more efficient way to go about it. (or am I going about this wrong?)
18:53:21
not in a single command, I think.
18:54:05
you can do INSERT INTO <new> { ?s ?p ?o } FROM <old> WHERE {?s ?p ?o}
18:54:24
and then DELETE FROM <old>
18:56:09
right. okay, I'll handle it that way. but I was surprised not to see a RENAME in the SPARUL spec. I think in ARCs datamodel this would be fairly trivial, right?
18:56:47
probably yes
19:00:27
something like RENAME <URI1> to <URI2> would be nice
19:00:41
then we could implement resource consolidation more easily
19:01:20
oh, a more general RENAME, I see.
19:02:40
I'm trying to so something quasi-transactional. E.g. Load a graph under a temporary name, tweak it a bit, and then 'commit' it under it's permanent name (maybe even overwriting a previous one).
19:04:21
or SET { <#me> ?p ?o } WHERE { ?some_id ?ifp ?o . <#me> ?ifp ?o . ?ifp a owl:InverseFunctionalProperty .}
19:04:28
hmmm
19:05:21
that'd be tricky to implement, though, I guess
19:06:04
I see, re graph pre-processing.
19:06:16
I have similar problems here, too
19:07:09
didn't find an ideal solutions yet, was thinking about a fully separate "inbox" store, but for now I'm adding annotations to to graphs to "flag" them as processed
19:07:55
e.g. I'm adding inferred triples directly to g1, so when g1 gets re-LOADed, the annotations are gone as well
19:08:16
and the inference bot will re-add them based on the new graph data
19:08:57
which has limitations, though
19:13:18
yes. I'd prefer that the incoming graph stay within it's own 'graph-space' while it was being pre-processed. Then, once that completed, I could insert (or replace an earlier version) in a permanent graph-name.
19:13:37
yeah, makes sense
19:15:41
I can certainly do that with LOAD <prepro>, ...tweak..., DELETE <main>, INSERT INTO <main> FROM <prepro>
19:16:14
but the post-tweaking step could be a lot more efficient if it didn't involve reloading a graph.
19:16:52
right
19:17:18
and you don't want to DELETE first for some quasi-transactional safety
19:17:47
any syntax suggestions?
19:18:25
MOVE GRAPH <a> TO <b>
19:19:00
REPLACE <a> WITH <b>
19:19:21
REPLACE GRAPH <a> WITH <b>
19:19:47
then I should perhaps align SPARQL+ with SPARUL and use INSERT INTO GRAPH instead of INSERT INTO
19:21:50
RESET GRAPH <a> FROM <b>
19:22:23
CREATE GRAPH <a> FROM <b>
19:25:50
bengee wonders if there's a simple UPDATE for triples, too, in there
19:27:32
right, the idea would be to keep <main> alive in it's old state until the new one was done preprocessing.
19:27:47
...and then replace it.
19:28:03
UPDATE <g1> {?s ?p ?o} WHERE { GRAPH <?g2> { ?s ?p ?o }}
19:34:29
Seems like there was a concerted effort to keep the UPDATE keyword out of the SPARUL spec. I think sticking to INSERT/DELETE simplifies a lot of implementation issues.
19:34:50
oh, really?
19:35:00
just guessing.
19:35:09
I've had requests for an UPDATE to bundle DELETE+INSERT
19:35:31
it would be nice to have it happen within the same transaction.
19:35:54
UPDATE in the SQL sense (SET VALUES(?binding1, ?binding2)) would be very hard to implement
19:36:15
but a triple- or quad-based UPDATE could be doable
19:36:20
right, especially if the object being updated was a uri.
19:37:19
UPDATE <g1> SET {<s> <p> "new o"} WHERE {<s> <p> "old_o"}
19:37:29
shouldn't be hard
19:38:09
I wonder if this could be tweaked to also cover your use case
19:38:16
right, but what it "new o" is a uri or bnode, do you need to check to make sure it exists?.... (for literals would be easy).
19:38:57
well the graph-name is a special case, right? it's not accessible as a triple... or is it?
19:40:19
UPDATE <g1> SET { ?s ?p ?o } FROM <g2> WHERE {?s ?p ?o}
19:41:23
but intuitively, this wouldn't clear g1 in advance but just add the triples from g2
19:41:38
right: "insert every ?s ?p ?o from <g2> into <g1>?"
19:42:09
UPDATE <g1> SET * FROM <g2>
19:42:32
not sure
19:42:49
maybe. but from a SQL background, UPDATE shouldn't ever delete anything.
19:43:04
(any triples that is)
19:43:08
true
19:43:24
then maybe a dedicated REPLACE might be beter
19:43:49
well if it's dedicated, I'd vote for RENAME GRAPH
19:44:04
but if you want something generic for renaming predicates, REPLACE could work.
19:44:35
sorry, subjects.
19:44:36
RENAME GRAPH makes sense
19:45:17
a generic REPLACE might have side-effects (with graph URIs appearing as subjects, too, etc)
19:45:49
so, RENAME GRAPH <g1> TO <g2>
19:45:54
sure.
19:46:14
which would replace a prior g2
19:46:51
Hmm. Should that be specific?
19:49:13
REPLACE <g1> WITH <g2> / REPLACE <g1> WITH {triples here}
19:49:27
would be pretty obvious, I think
19:49:49
right, and it would create <g2> if it didn't already exist?
19:49:56
yes
19:50:14
s/g2/g1/
19:50:33
right.
19:52:50
it might work for your consolidation issues too. you just want to be able to replace <predicate a> with <predicate b>? throughout a the graph?
19:53:19
rather a subject with some canonical one
19:53:38
sorry: s/predicate/subject/
19:53:45
yep
19:54:11
don't know why predicate keeps slipping out... it's just so fun to say.
19:54:16
heh
19:55:01
so then:
19:55:11
REPLACE <s1> WITH <s2> FROM NAMED <g>
19:55:15
or
19:55:52
REPLACE GRAPH <g1> WITH <g2> / REPLACE GRAPH <g1> WITH {triples here}
19:55:54
?
19:57:34
dunno ;)
19:57:41
just a thought.
19:58:49
hey, what about SET <g1> TO <g2>
19:59:23
the we don't have the existence issue implied by REPLACE
19:59:34
s/the we/then we/
20:00:00
sure.
20:01:13
will think about this a little
20:01:19
whatever makes the most sense.
20:01:45
I'll press on with LOAD, tweak, DELETE, INSERT INTO
20:01:48
yeah, maybe best to implement *something* first instead of losing time over naming
20:02:02
true.
20:02:54
I'll prolly end up with RENAME GRAPH anyway
20:02:58
;-)
20:04:35
nice chatting with you. I'll keep an eye on semsol.org in case you decide to implement something. Thanks for helping me think about my problem.
20:05:23
likewise, thx for the input
20:05:53
np. ttyl.