IRC log of dig on 2011-01-13

Timestamps are in UTC.

12:32:10 [DIGlogger]
DIGlogger (~dig-logge@groups.csail.mit.edu) has joined #dig
12:32:10 [verne.freenode.net]
topic is: Decentralized Information Group @ MIT http://dig.csail.mit.edu/
12:32:10 [verne.freenode.net]
Users on #dig: DIGlogger RalphS Yudai__ IvanHerman tlr kennyluck timbl sandro ericP amy webr3 danbri IPaparrizos jambo gbot30 nunnun
12:45:58 [amy]
amy has quit (Quit: byee)
13:27:00 [timbl_]
timbl_ (~timbl@pool-96-237-236-230.bstnma.fios.verizon.net) has joined #dig
13:27:42 [timbl_]
timbl_ has quit (Client Quit)
13:30:24 [timbl]
timbl has quit (Ping timeout: 240 seconds)
13:42:09 [melvster]
melvster (~melvster@p579F9F3A.dip.t-dialin.net) has joined #dig
14:37:12 [oshani]
oshani (~oshani@31-34-156.wireless.csail.mit.edu) has joined #dig
14:54:05 [lkagal]
lkagal (~lkagal@pool-96-237-240-136.bstnma.fios.verizon.net) has joined #dig
14:54:06 [tlr]
tlr has quit (Quit: tlr)
14:55:03 [amy]
amy (~amy@30-6-83.wireless.csail.mit.edu) has joined #dig
15:10:00 [presbrey]
presbrey (~presbrey@SCRIPTS.MIT.EDU) has joined #dig
15:11:40 [lkagal]
lkagal has quit (Quit: lkagal)
15:43:28 [lkagal]
lkagal (~lkagal@pool-96-237-240-136.bstnma.fios.verizon.net) has joined #dig
15:51:02 [junaidnaseer]
junaidnaseer (~junaid@pc222.phh.uni-kiel.de) has joined #dig
15:57:10 [oshani]
oshani has quit (Quit: Mama nidi!)
16:12:12 [IvanHerman]
IvanHerman has quit (Quit: bye guys)
16:20:14 [oshani]
oshani (~oshani@31-34-156.wireless.csail.mit.edu) has joined #dig
16:20:52 [timbl]
timbl (~timbl@31-35-193.wireless.csail.mit.edu) has joined #dig
16:21:50 [marisol]
marisol (~marisol@pool-141-154-123-139.bos.east.verizon.net) has joined #dig
16:34:26 [Pipian_]
Pipian_ (~pipian@w3cdhcp27.w3.org) has joined #dig
17:03:55 [oshani]
oshani has quit (Quit: Mama nidi!)
17:45:37 [betehess]
betehess (~betehess@betehess.w3.org) has joined #dig
17:50:04 [junaidnaseer]
junaidnaseer has quit (Ping timeout: 276 seconds)
18:12:55 [oshani]
oshani (~oshani@31-34-156.wireless.csail.mit.edu) has joined #dig
18:18:54 [junaidnaseer]
junaidnaseer (~junaid@pc222.phh.uni-kiel.de) has joined #dig
19:03:11 [marisol]
marisol is now known as mari-brb
19:12:14 [mari-brb]
mari-brb has quit (Quit: mari-brb)
19:31:03 [jambo]
jambo has quit (Ping timeout: 260 seconds)
19:43:51 [jambo]
jambo (~jambo@nat/google/x-ijupgskmfyrxjnoy) has joined #dig
19:49:30 [Pipian_]
webr3, are you in?
19:56:06 [webr3]
yup
19:57:02 [Pipian_]
Just ran across your proposal for an RDF API in the process of doing some research for something ericP asked me about last month
19:57:19 [webr3]
ahh cool - which one?
19:57:32 [Pipian_]
http://webr3.org/apps/play/api/lib
19:57:33 [Pipian_]
That one
19:58:29 [webr3]
ahh cool - that's a bit old now - on to http://www.w3.org/2010/02/rdfa/sources/rdf-api/
19:58:37 [webr3]
which I'm actually implementing today
19:58:48 [webr3]
anyway, minor digression - how can I help?
20:00:28 [Pipian_]
Well, ericP had asked me about how a permanent in-browser RDF store would be implemented, which I don't think the RDF API proposals really address(??)
20:00:41 [Pipian_]
Hitting indexedDB for example.
20:01:49 [ericP]
Pipian_, are you at the 'tute?
20:02:19 [ericP]
alexandre's been working on the API too
20:02:34 [Pipian_]
Yeah
20:02:42 [ericP]
(had interests which recently depositeh him in this space)
20:03:06 [ericP]
you might want to poke him and see if you guys have some intersection in your API visions
20:03:32 [webr3]
Pipian, that's something I'm v interested in too - webworker + shared store (indexed db or suchlike) seems to be the approach, but I haven't had time to look properly yet
20:03:38 [Pipian_]
I haven't really drafted any API, and in fact, having a concrete draft of an API is more helpful in that I don't have to come up with one myself.
20:04:16 [Pipian_]
Although making sure that the old cwm and RDFQuery APIs could be modeled on top would have been my only real concern.
20:04:34 [webr3]
Pipian, if you want to look at an in browser rdf store and getting one implemented, I'd be happy to do that, we've talked about spec'ing one often in the RDFa WG and may be able to publish a note about one
20:04:55 [webr3]
myself, mark and manu all v interested (and yourself, eric, dan, tim to i'd imagine)
20:05:33 [ericP]
i'm only sort of interested, but apparently obsessed with aligning efforts on it
20:06:41 [Pipian_]
Sure. I can take a look at what I can do with deriving an RDF API implementation that touches it. Nothing local to the browser yet so much as a layer on top of what's already there.
20:06:52 [Pipian_]
Since it should be possible.
20:07:06 [timbl]
Alex has been working on et API def or the code
20:07:17 [webr3]
Pipian, it should be - one of the first questions is triple store vs graph store vs quad store
20:07:39 [timbl]
cwm and tabulator are quite close
20:08:07 [timbl]
a formula looks like a triple store
20:08:11 [Pipian_]
My current instincts were to go for a quad store, since it was the most straightforward to outline in indexedDB
20:08:47 [Pipian_]
Whether the quad store is represented as a collection of formulas or not is a different story.
20:09:25 [timbl]
most RDF processing from the API point of view happens with respect to a common graph content
20:09:30 [Pipian_]
But at least, given the tabular form of indexedDB, it'd be easier to make a quad store compared to anything else if we want support for quads.
20:09:50 [timbl]
most of the time you don't watn the quad bit explicit as fourth param
20:09:58 [timbl]
you want it implcit in htegraph you are talking to
20:10:05 [Pipian_]
Indeed, which is why it looks like the RDF API proposal has an RDFGraph class with all the interesting APIs dangling from it.
20:10:08 [webr3]
I was tempted towards triple store w/ formula, and .. just as tim said
20:10:19 [timbl]
Lets not confuse the API with ho wit i simpl;emented
20:10:31 [timbl]
underneath most systems use quadstores
20:10:36 [Pipian_]
Yeah, those are clearly two different things.
20:10:45 [timbl]
tabulator and cwm are basically quadstores
20:11:04 [timbl]
but the rdf API by defintion is trpley
20:11:08 [Pipian_]
API-wise I agree with the formula approach in general.
20:11:10 [timbl]
tripley
20:11:17 [ericP]
timbl, alexandre and i wrote some DirectMapping code a while ago, leaning on a trivial concrete implementation of the RDF spec
20:11:24 [ericP]
he recently tweaked it to talk to an interface, reallized either by both our trivial RDF implementation and a little Jena wrapper
20:11:51 [ericP]
he intends to add the little wrapper around Sesame soon
20:12:06 [ericP]
so this interface looks a lot like an API
20:12:15 [timbl]
Could you produce the (tabulatro or cwm) RDF api on top of the direct mappingstuff?
20:12:34 [ericP]
there are some out there already, and the goal is to see which are the best to steal and tweak
20:14:59 [ericP]
timbl, so the tabulator would render RDBs for you?
20:16:19 [timbl]
for exampl
20:16:27 [Pipian_]
So, looking over the API, I think the only real thing that would need a special implementation for in-browser store support would be the Graph interface
20:16:43 [Pipian_]
(assuming that RDF API was the way it was implemented)
20:18:42 [betehess]
do you guys know if cwm can work with jython?
20:19:07 [betehess]
if yes, it could easily become another backed in FeDeRate
20:19:14 [webr3]
Pipian_ see also: http://lists.w3.org/Archives/Public/public-rdfa-wg/2010Nov/0029.html
20:19:30 [betehess]
s/backed/backend
20:20:39 [webr3]
timbl, do you think it would do any good to start work on an unofficial draft of a/the Linked Data Protocol, and also a generalized rdf serialization half way between Turtle and N3?
20:23:41 [betehess]
webr3, "graph as immutable datastructure" does not mean that you can't remove triples
20:25:37 [betehess]
I did not follow the work on the RDF API, I just hope you'll follow the spec, and that you will distinguish Subject, Predicate and Object in their types
20:26:25 [Pipian_]
betehess, given the current draft, it seems that removing triples is possible
20:26:31 [betehess]
ok
20:26:32 [Pipian_]
(the remove() function on the Graph interface)
20:26:40 [webr3]
betehess, tbh the work is just about to start, new charter coming up - I assume you mean constrained rdf w/ iri/bnode subject, iri predicate, no graph literals?
20:27:05 [betehess]
something like that, yes
20:27:20 [betehess]
for example, the Jena guys got it totally wrong in that regard
20:27:53 [webr3]
re remove: yes it's possible w/ current interface, there was some context where some distinction was made between a graph which you could remove from being a store rather than a graph - see start of http://lists.w3.org/Archives/Public/public-rdfa-wg/2010Nov/0032.html for more
20:28:10 [webr3]
current API draft is up above ^^
20:28:35 [betehess]
you can think about this problem as isomorphic relations between the entities, as in https://dvcs.w3.org/hg/FeDeRate/file/20c3a5b0af1e/rdf/src/main/scala/RDF.scala#l35
20:28:49 [webr3]
betehess, and yes re Jena (and your comment getting it wrong) see: http://lists.w3.org/Archives/Public/public-rdfa-wg/2011Jan/0070.html for the latest on that
20:30:48 [Pipian_]
There are plenty of people who would be happy to see graph literal support even though it's not yet in an official RDF serialization :)
20:31:11 [oshani]
oshani has quit (Quit: Mama nidi!)
20:31:28 [betehess]
webr3, interesting
20:32:00 [Pipian_]
(N3 users, for one)
20:32:09 [Pipian_]
But I digress.
20:32:16 [betehess]
maybe not :-)
20:37:20 [webr3]
yes - and a lot of people who need rules and reasoners
20:37:49 [webr3]
ivan outlined the problem and use case in an earlier mail - can get pointer if you want
20:40:33 [webr3]
did you forget to ask santa?
20:40:44 [amy]
:)
20:40:45 [webr3]
danbri, sparql 1 or 1.1?
20:41:00 [danbri]
can beggers be choosers?
20:41:10 [betehess]
actually, we can compile JVM bytecode to javascript
20:41:19 [webr3]
well if it needs implemented..
20:41:48 [webr3]
betehess, hows the js it produces? I've tried ocamljs and emscripten but neither are.. well dev friendly output
20:42:16 [betehess]
what do you mean by dev friendly?
20:42:30 [betehess]
you only want a cool interface in the API
20:42:39 [betehess]
and don't care about the implementation
20:42:52 [betehess]
oh, wait, you're a JS guy, I forgot ;-)
20:42:56 [timbl]
betehess, if something is immutable you can change it?
20:43:18 [betehess]
timbl, it's not the right angle
20:43:50 [webr3]
betehess, something one can maintain and that other js dev's will use :p
20:43:54 [betehess]
it just means you don't change a structure using side-effects
20:44:57 [timbl]
Ah -- it doesn't smutate behind the scenes?
20:45:07 [betehess]
exactly
20:45:10 [timbl]
The cwm formulae are either open or closed.
20:45:17 [timbl]
When you are parsing into one it is open.
20:45:26 [timbl]
When you close it, it get sindexed
20:45:47 [webr3]
context: I used the word immutable when discussing rdf graph interface, wrong specific term but couldn't think of the correct one, see http://lists.w3.org/Archives/Public/public-rdfa-wg/2010Nov/0031.html for explanation "without forking the discussion too much..." paragraph
20:46:00 [timbl]
Also it can be canonicalized --- return you another copy it already has -- which is probably a waste of time
20:46:36 [timbl]
bethgess, what do you have against generalized triples?
20:46:54 [betehess]
webr3, you used immutable the right way, but it doesn't mean you cannot define a graph as a graph minus some triple
20:47:11 [betehess]
timbl, only one thing: it's not in the spec :-)
20:47:40 [betehess]
but I don't care actually
20:47:58 [webr3]
betehess, indeed - practical distinction between a graph which is a subgraph of another minus one triple and removing a triple isn't worth debating implementation wise :)
20:48:12 [betehess]
I don't agree
20:48:21 [betehess]
it's actually extremely important
20:48:27 [betehess]
because:
20:48:32 [betehess]
(let me think about an example)
20:49:05 [webr3]
betehess, did you see above link? (here w/ more context) http://lists.w3.org/Archives/Public/public-rdfa-wg/2010Nov/0032.html - may be the same conclusion
20:50:04 [webr3]
btw, hi betehess, don't think we've talked before
20:50:08 [betehess]
[[ Hm... well, conceptually that might be true although this would lead to a kind of a philosophical debate. But that does not mean that you cannot remove a triple from a specific Graph! That does not remove the triple from the universe, just its association with a specific graph instance... ]] that effectively isn't the definition for immutable
20:50:15 [betehess]
hi! :-)
20:51:41 [betehess]
immutable just avoid weird side-effects, and it doesn't mean you don't have efficiency. As an implementer, you just have to think twice hard, but you make the like of the users of a library a lot happier
20:52:38 [webr3]
indeed - however I'm struggling to grok your main point here, that graphs should have a remove method or not?
20:52:55 [timbl]
The RW sem web stuff is all defined i nterms o fmutating graphs
20:53:03 [betehess]
yes, but that would return a pointer to another graph
20:53:14 [betehess]
that may share some data with the previous one
20:53:23 [betehess]
instead of modifying the graph itself
20:53:32 [webr3]
betehess, okay, so immutable and passed by value rather than reference
20:54:25 [betehess]
why? it's ok to pass by reference :-)
20:54:47 [betehess]
val g1 = new Graph() + some triples ; val g2 = g1 - triple
20:54:56 [webr3]
could have memory implications - wonder if it's expected functionality or not.. technically i guess the two graphs aren't equal and thus are two different graphs, thus immutable, thus should return a new graph as you say - but practically i wonder if it introduces a problem
20:54:58 [betehess]
in this example, I expect g1 not being modified
20:55:34 [betehess]
it's actually always easier to deal with memory in the case of immutability
20:55:36 [webr3]
betehess, but given the context and g1.remove(t) you'd expect g1 o return a g2?
20:55:45 [betehess]
yes
20:55:47 [webr3]
s/o/to
20:56:05 [betehess]
but it doesn't mean that all the data is copied
20:56:06 [Pipian_]
In a truly immutable world that would make sense.
20:56:28 [webr3]
Pipian, agree - i worry that it's not expected functionality in js world though
20:56:31 [Pipian_]
Of course people like mutable stuff too :)
20:56:42 [webr3]
(unlike filter which treats as immutable)
20:56:58 [Pipian_]
To be fair, I don't think js has worried itself over immutability the way the Java folks do.
20:57:03 [betehess]
well, don't practice immutability too much, you won't want to come back
20:57:27 [betehess]
oh don't worry, most of the java guys don't get it either :-)
20:59:10 [webr3]
timbl, good point re rw and mutating graphs
21:01:07 [betehess]
they don't have a choice a the pointer is the URL. in a real programming language, you get a new pointer with a new variable
21:01:33 [betehess]
let gives that to the philosophers
21:02:05 [oshani]
oshani (~oshani@31-34-156.wireless.csail.mit.edu) has joined #dig
21:03:20 [webr3]
agree, could just keep going w/ this convo all night
21:03:46 [oshani]
oshani has quit (Client Quit)
21:04:35 [timbl]
It sounds as though the immutable way of thinking is like the http://www.w3.org/DesignIssues/PaperTrail way of thinking, where all data is immutable, and the current state is a function of what you know, not a varibale you cnage.
21:04:44 [timbl]
is that right, behetess?
21:04:56 [betehess]
let me read the paper
21:05:50 [webr3]
timbl, that paper helped me masses in many resent comments in sem web and rest groups - esp sn= P(mn, sn-1, t) model
21:05:59 [webr3]
s/resent/recent
21:06:09 [timbl]
Sandro has suggested in fact we should not use sparql delete at all, but jsut allow people to utter things which are now correct, letting things which are inconsistent with that being deemed superseded.
21:07:28 [webr3]
that would be nice, iirc i had the same discussion w/ sandro a few weeks ago - rdf diff and patch comes to mind, as does PATCH verb, and.. you could always POST new triples to a "document that accepts annotations" - quite a few approaches technically
21:09:29 [webr3]
makes a lot of sense if you consider each dereferencable uri as identifying an (intelligent) agent which manages the current state of a resource (updated via messages)
21:10:18 [betehess]
timbl, to answer "It sounds as though the immutable way of thinking is like..." -> yes!
21:10:49 [timbl]
Ah, we are on the same wavelength there then.
21:11:32 [timbl]
Except the code I am writing is very much not like that -- but it could be .. just list all the incoming SPARQL requests in list of immutable things
21:11:35 [betehess]
this is the semantics given to "variable allocation" in a decent programming language
21:12:28 [betehess]
s/allocation/declaration/
21:13:20 [betehess]
in an immutable world, each operation creates a value instead of modifying things using a side-effect
21:13:41 [betehess]
a URI acts as a variable reference
21:14:05 [betehess]
this system imposes you to use side-effects
21:15:33 [betehess]
the web is so b0rken :-)
21:17:01 [betehess]
btw, the one who wrote sn= P(mn, sn-1, t) sure knows information theory and signal processing :-)
21:18:20 [webr3]
betehess, +1 to that - most useful little function I've came across in a long time
21:19:14 [RalphS]
RalphS has quit (Quit: outah here ...)
21:43:44 [oshani]
oshani (~oshani@31-34-156.wireless.csail.mit.edu) has joined #dig
22:55:17 [junaidnaseer]
junaidnaseer has quit (Ping timeout: 264 seconds)
23:10:30 [timbl]
timbl has quit (Quit: timbl)
23:10:44 [junaidnaseer]
junaidnaseer (~junaid@pc222.phh.uni-kiel.de) has joined #dig
23:11:18 [Pipian_]
Pipian_ has quit (Remote host closed the connection)
23:17:28 [junaidnaseer]
junaidnaseer has quit (Quit: Leaving.)
23:35:16 [Martinp23]
[Global Notice] Hi folks! We're about to replace our SSL certificates which could result in some disruption. If stuff gets noisy, please accept our apologies. If you have difficulties using SSL in the next few days, tell us in #freenode. In any case, watch the blog and wallops (/umode +w) for further updates. Cheers!