IRC log of dig on 2012-06-11

Timestamps are in UTC.

11:25:14 [DIGlogger]
DIGlogger (~dig-logge@groups.csail.mit.edu) has joined #dig
11:25:14 [zelazny.freenode.net]
topic is: Decentralized Information Group @ MIT http://dig.csail.mit.edu/
11:25:14 [zelazny.freenode.net]
Users on #dig: DIGlogger RalphS cheater_ deiu melvster bblfish rszeno kennyluck ericP manu1 dsheets presbrey manu-db nunnun_away mattl bergi Yudai_
11:31:51 [bblfish]
good morning DIGlogger
11:49:19 [melvster1]
melvster1 (~melvin@p4FF97317.dip.t-dialin.net) has joined #dig
11:50:40 [melvster]
melvster has quit (Ping timeout: 246 seconds)
11:54:38 [dsheets]
dsheets has quit (Ping timeout: 240 seconds)
11:55:00 [dsheets]
dsheets (~Adium@c-71-198-141-58.hsd1.ca.comcast.net) has joined #dig
11:59:07 [dsheets]
dsheets has quit (Ping timeout: 250 seconds)
12:29:48 [RalphS]
RalphS has quit ()
12:36:50 [betehess]
betehess (~betehess@tightlips.w3.org) has joined #dig
12:55:06 [bblfish]
betehess: hi, good morning. Just working on read-write-web play. Just wanted to ask you a question with regard to message architecture
12:58:50 [bblfish]
currently working on improving body parser so that it can return a union type of [rdf#Graph v rdf#Query v RawBuffer]
12:59:53 [bblfish]
then I was going to send those to the actor with info on what was meant to do with it. PUT(graph, path) or PUT(image, path)...
13:00:04 [bblfish]
still looking into all the types of messages I would need
13:01:09 [bblfish]
just wondering if there were some guidelines for how to build messages
13:01:11 [betehess]
when you say Union Type, you mean Algebraic DataType? or you want to use the union type encoding? (which is not the best idea IMO)
13:01:30 [bblfish]
yes, just looking at http://www.chuusai.com/2011/06/09/scala-union-types-curry-howard/
13:01:36 [betehess]
for messages, just use case classes
13:01:50 [betehess]
well, that's exactly the thing you should not use
13:01:58 [betehess]
you don't need that
13:02:06 [bblfish]
ah (I saw you +1 that article though)
13:02:10 [betehess]
just use sealed case class
13:02:54 [betehess]
well, that's a great article to see how to use Curry-Howard, it does not mean this is something you want to use for real
13:03:00 [betehess]
and case classes are just good
13:03:19 [bblfish]
case classes are good for messages right?
13:03:23 [betehess]
yes
13:03:59 [bblfish]
I was thinking of using curry-howard for trait BodyParser[+A] extends Function1[RequestHeader, Iteratee[Array[Byte], Either[Result, A]]]
13:04:05 [betehess]
ahhh
13:04:09 [bblfish]
for the A in there
13:04:43 [bblfish]
ah!
13:04:54 [betehess]
just start with case classes :-)
13:04:55 [bblfish]
:$
13:05:03 [betehess]
you'll see later if you really need something else
13:05:11 [betehess]
why wouldn't you want to use them?
13:05:47 [bblfish]
Well A can be one of 3 types I think in BodayParser: Graph, Query, or some binary
13:06:16 [betehess]
perfect for ADT
13:06:16 [bblfish]
case classes don't do disjunction like that
13:06:22 [betehess]
yes they do
13:06:30 [betehess]
they are meant for taht actually
13:06:54 [betehess]
the question is: do you *want* tagged union, or untagged union
13:06:58 [bblfish]
ah, I see you have subclasses ok
13:07:11 [betehess]
untagged == miles' article
13:07:17 [betehess]
tagged = case classes
13:07:19 [bblfish]
you make a trait Answer
13:07:27 [bblfish]
and then GraphAnswer extends Answer ...
13:07:34 [betehess]
sealed gives you exhaustivity
13:07:37 [betehess]
yes
13:07:44 [bblfish]
ok
13:08:25 [bblfish]
then is there anything clever to do with the messages I send? Should I have a PUT message a GET message? Or is it just going to fall out by itself?
13:09:04 [bblfish]
I was also wondering if I should have differnt resource actors: one for Graph resources, and another resource actor for say images...
13:09:07 [betehess]
just translate every message in a case class
13:09:23 [betehess]
depends
13:09:41 [betehess]
you can have one kind of actor that understands everything
13:10:05 [betehess]
I don't think this is what we want in this case
13:10:18 [bblfish]
actors have state. so graph actors probably want a graph variable
13:10:19 [betehess]
because actors are only identified by their uri
13:10:23 [betehess]
s/uri/path/
13:10:28 [bblfish]
yes.
13:11:14 [betehess]
well, you could use mix-ins for your actors, to combine their possible states and their receive methods
13:11:39 [betehess]
if you don't do that, you'll need guards that will identify the type of message being sent
13:11:53 [betehess]
and then the routing will need to know this information
13:11:59 [betehess]
its cumbersome I believe
13:12:02 [betehess]
but I may be wrong
13:12:28 [bblfish]
ok, will look at mix-ins
13:12:30 [betehess]
I would start with only one implementation
13:12:32 [bblfish]
did not know about those
13:12:37 [betehess]
even without mixins
13:12:39 [bblfish]
good idea
13:13:01 [betehess]
if you need composition, I'll introduce mixins (it's only about refactoring)
13:13:37 [bblfish]
ok. I have a simple implementation already https://github.com/bblfish/Play20/blob/webid/framework/src/webid/src/main/scala/org/w3/readwriteweb/play/ResourceManager.scala
13:13:45 [bblfish]
not well designed but it worked
13:13:46 [betehess]
and if you have performance issues (eg. too many different states within one single actor), I would introduce guardians actors
13:14:06 [betehess]
sadly, won't have time today
13:14:31 [bblfish]
ok. It's only a page long, and easy to grasp in 30 secs
13:14:39 [betehess]
good :-)
13:14:49 [bblfish]
is mixins an akka concept?
13:15:03 [betehess]
no no, it's plain Scala
13:15:07 [betehess]
traits mixins
13:15:18 [bblfish]
ah ok
13:15:39 [bblfish]
ah so you'd still ahve one big actor, but it would be readable :-)
13:16:13 [betehess]
yes
13:16:34 [betehess]
the neat thing is how you could compose the receive method
13:16:41 [betehess]
anyway, /me need to go now
13:16:51 [bblfish]
ok, thanks for the directions....
13:16:54 [betehess]
sure
13:17:48 [bblfish]
mind you curry howard saves you from one wrapping. Perhaps in memory contained situations that is important
13:20:33 [bblfish]
betehess: just when you get time, can you vote for pull request https://github.com/playframework/Play20/pull/339 so I get something in play
13:52:44 [amy]
amy (~amy@30-6-207.wireless.csail.mit.edu) has joined #dig
14:32:34 [bblfish]
well aparently union types only work in functions, not in objects...
14:46:43 [bblfish]
betehess: is it not a bit odd that your sparql queries don't have a common supertype?
14:47:52 [bblfish]
As a result I think one needs to wrap the select query in a SELECT(query) case class, and the ASK(query) in an ask case class
14:49:18 [betehess]
what would their share (I'm speaking about the common interface)?
14:49:23 [betehess]
s/their/they/
14:49:37 [betehess]
(/me on and off, still in meetings)
14:50:01 [bblfish]
as for example here https://github.com/w3c/banana-rdf/blob/master/rdf/src/main/scala/AsyncSPARQLEngine.scala
14:50:21 [bblfish]
a query is a function on a graph that returns a result
14:50:34 [betehess]
what result?
14:50:37 [bblfish]
the result can be a new graph (UPDATE)
14:50:40 [bblfish]
or a row
14:50:48 [bblfish]
or a truth value
14:50:55 [betehess]
you need to know the kind of query you have to know the kind of result
14:51:27 [betehess]
tell me what you want to achieve
14:51:29 [bblfish]
so its function(Graph) => Result
14:51:38 [betehess]
so what is Result?
14:51:57 [betehess]
and btw, s/Graph/RDFStore/
14:52:00 [bblfish]
I suppose result is itslef a graph
14:52:04 [betehess]
no
14:52:06 [betehess]
it depends
14:52:18 [betehess]
as you said, can be booealn, rows, graph, etc.
14:52:25 [bblfish]
rows, are graphs
14:52:28 [betehess]
what do they have in common?
14:52:37 [betehess]
no
14:52:46 [bblfish]
you can describe a row as a graph
14:52:53 [bblfish]
it's quite simple
14:52:56 [betehess]
or you have a very loose definition for graph
14:53:05 [bblfish]
a graph is a set of statements
14:53:07 [betehess]
you don't want to manipulate a graph there
14:53:12 [betehess]
you want... rows
14:53:28 [bblfish]
ok, a row is a special type of graph
14:53:40 [betehess]
you'll have to prove me the value of encoding a row as a graph for this particular API
14:54:19 [betehess]
it's not defined like that in the spec, and none of the implementations I know do anything close to that
14:54:31 [bblfish]
mhh
14:54:47 [betehess]
if you say it's a graph, you won't do much with this information
14:54:55 [bblfish]
still it's odd to have different types of queries, and then not to match on the type of query
14:55:05 [betehess]
it's like I give you back XML all the time
14:55:14 [bblfish]
well for sure a query always has a graph as argument
14:55:14 [betehess]
and I tell you: it's enough to encode RDF
14:55:32 [betehess]
tell me what you need to achieve
14:55:49 [bblfish]
well don't we want something like
14:56:09 [bblfish]
query match { case select: Select => ... case ask: Ask => ... }
14:56:17 [betehess]
you can do that
14:56:27 [betehess]
it does not have to be provided by this typeclass
14:56:46 [bblfish]
well here you wrap them https://github.com/w3c/banana-rdf/blob/master/rdf/src/main/scala/AsyncSPARQLEngine.scala
14:56:47 [betehess]
I would discourage you to use type matching here
14:56:55 [betehess]
as they can all share the same type
14:56:58 [betehess]
eg. String
14:57:16 [betehess]
they are never wrapped
14:57:20 [betehess]
and I don't want to
14:57:21 [bblfish]
ah yes
14:57:29 [bblfish]
true, you don't wrap them
14:57:35 [betehess]
because there is no need for that here
14:57:54 [betehess]
you just want to satisfy some constraints, that are enough for the provided functions
14:58:31 [bblfish]
I was just wondering how to use this in my BodyParser
14:58:40 [betehess]
you can define you own ADT
14:58:46 [bblfish]
presumably I need to create Select, Ask, etc, classes ...
14:59:04 [betehess]
sure
14:59:31 [betehess]
the current framework does not tell you how to distinguish from 2 sparql queries
14:59:37 [betehess]
we may want to provide that
14:59:45 [betehess]
but this would be another typeclass
15:00:10 [bblfish]
but I have to distinguish them? Perhaps not...
15:00:26 [bblfish]
need to look at this more carefully...
15:00:28 [betehess]
and there would not be a shared type in https://github.com/w3c/banana-rdf/blob/master/rdf/src/main/scala/SPARQL.scala
15:01:16 [betehess]
again, we can provide the ADT in banana-rdf, but there would not be this constraint in SPARQL.scala
15:01:40 [bblfish]
ok, I need to see how I would write a body parser for sparql queries
15:01:57 [bblfish]
then I'll see what that returns
15:02:07 [betehess]
yep
15:02:20 [betehess]
let your needs drive your design
15:02:26 [bblfish]
merci :-)
15:02:38 [betehess]
don't make the mistake I made several times in the past: overthink your design :-)
15:02:56 [sandro]
sandro (~sandro@ssh.w3.org) has joined #dig
15:10:47 [bblfish]
betehess: mind you your SPARQL engine does not have UPDATE , I thought we needed that for updating rdf graphs in read-write-web https://github.com/w3c/banana-rdf/blob/master/rdf/src/main/scala/SPARQLEngine.scala
15:11:41 [betehess]
hrmmm, right
15:12:48 [betehess]
then it would be fairly easy
15:13:18 [betehess]
but we could add Update to SPARQL.scala
15:13:22 [betehess]
in the meantime
15:13:31 [betehess]
hrmmm
15:13:35 [bblfish]
ok, I'll work with what's there for the moment, and then add it when I understand how it works
15:13:49 [bblfish]
(if you think it can be added easily)
15:14:20 [betehess]
I'm afraid that a file-based sparql engine won't allow us to support update anyway
15:14:27 [betehess]
we'll break the semantics
15:14:39 [betehess]
update is ok for a real store
15:15:13 [bblfish]
no I think file based would work: it works for the famous couchDB
15:15:36 [bblfish]
we just need to have some HTTP redirection to the old or new versions
15:15:45 [bblfish]
I think
15:15:58 [bblfish]
aparently couchDB does something like that: they can keep all the versions
15:17:14 [betehess]
I believe that Update can let you update several graphs at once
15:17:19 [bblfish]
( that's what the Javascript expert in Berlin told me. CouchDB is written in Erlang and so fully functional. )
15:17:31 [betehess]
yes sure
15:17:33 [bblfish]
ah well we would need to remove that functionality probably
15:17:39 [betehess]
but you're doing something different there
15:17:44 [betehess]
one graph == one file
15:18:06 [betehess]
anyway
15:18:20 [bblfish]
I'd need to think about it...
15:18:28 [bblfish]
something to discuss in more detail...
15:18:29 [bblfish]
later
15:18:49 [betehess]
supporting Update was too difficult for IBM
15:18:58 [betehess]
that's why they want a PATCH
15:19:04 [bblfish]
ah ok
15:19:06 [betehess]
targeting one resource
15:19:38 [bblfish]
yes, I was thinking one would limit the UPDATE to whatever PATCH would be
15:19:56 [bblfish]
s/would be/will be/
15:20:05 [betehess]
that's the point for PATCH
15:20:24 [betehess]
being a subset of UPDATE
15:20:43 [bblfish]
ah ok. still we need PATCH then :-)
15:20:56 [betehess]
which we don't know yet!
15:21:06 [bblfish]
ah well it's a subset of UPDATE
15:21:15 [bblfish]
that's good enough for our demos
15:32:00 [deiu]
deiu has quit (Ping timeout: 244 seconds)
15:48:40 [nunnun_away]
nunnun_away is now known as nunnun
16:06:07 [bblfish]
betehess: I seem to notice that the way things are set up one needs a graph store to write triples to. And the lib seems to be based on using akka to send messages to do that. Is that still the right way to do things if we have one a store per file on the system? Or is it that we should perhaps move to place the index in a central graph store and keep the files on the hard drive as backup?
16:06:49 [bblfish]
( in context of using banana for read-write-web of course )
16:07:43 [bblfish]
ah there is AsyncGraphStore and GraphStore.... perhaps looking at GraphStore
16:38:37 [bblfish]
ah found it SPARQLOperations is the place to look
16:41:21 [bblfish]
I suppose this is where it would be useful to have a general query engine
16:41:43 [bblfish]
because the engine should not need to know in advance what type of query it is receiving
16:41:56 [bblfish]
as long as the mime type is application/sparql-query
16:42:40 [bblfish]
My guess is that each of these engines knows how to take a SELECT, CONSTRUCT, ASK, UPDATE query and return the right type of query
16:44:14 [bblfish]
indeed
16:47:04 [bblfish]
betehess: Jena and Sesame know how to create a Query object out of any Query
16:47:55 [bblfish]
( well sesame in your framework only takes Strings )
16:49:19 [bblfish]
even here http://www.openrdf.org/doc/sesame2/api/
16:49:49 [bblfish]
so I do think that we need to model queries in a less brittle fashion.
16:53:24 [bblfish]
( I notice that both Jena and Sesame, have query objects that allow one to reset bindings, and alter the query for example)
17:20:09 [bblfish]
what is clear is that a query is something like a graph that contains 0 or more variables that are to be bound.
17:22:01 [bblfish]
then the different query formst are SELECT => bind the variables, CONSTRUCT=> bind the variables and return the graphs that fit the pattern ASK => does any graph satisfy the variables (if any)
17:22:56 [bblfish]
UPDATE: create a new graph version by applying the transformation
17:26:53 [bblfish]
I think in n3 there is the notion of a formula
17:27:06 [bblfish]
which is a graph with variables that can be matched
17:47:54 [Yudai_]
Yudai_ has quit (*.net *.split)
17:48:26 [Yudai_]
Yudai_ (~Yudai@nttkyo089248.tkyo.nt.ngn2.ppp.infoweb.ne.jp) has joined #dig
19:17:34 [Yudai_]
Yudai_ has quit (Ping timeout: 255 seconds)
19:19:41 [Yudai_]
Yudai_ (~Yudai@nttkyo089248.tkyo.nt.ngn2.ppp.infoweb.ne.jp) has joined #dig
19:56:45 [timbl]
timbl (~timbl@31-35-252.wireless.csail.mit.edu) has joined #dig
19:56:51 [nunnun]
nunnun is now known as nunnun_away
20:18:55 [nunnun_away]
nunnun_away is now known as nunnun
20:21:36 [nunnun]
nunnun is now known as nunnun_away
20:39:19 [dsheets]
dsheets (~Adium@c-71-198-141-58.hsd1.ca.comcast.net) has joined #dig
21:04:31 [timbl]
timbl has quit (Quit: timbl)
21:31:12 [bblfish]
betehess: It looks like the Sesame implmentation could use better types. They have three subtypes of a Query object: BooleanQuery, TypleQuery and GraphQuery, which I suppose corresponds to ASK, SELECT and CONSTRUCT
21:31:18 [bblfish]
http://www.openrdf.org/doc/sesame2/api/
21:34:42 [dsheets]
dsheets has quit (Ping timeout: 244 seconds)
21:36:54 [dsheets]
dsheets (~Adium@c-71-198-141-58.hsd1.ca.comcast.net) has joined #dig
21:44:46 [manu-db]
manu-db has quit (Remote host closed the connection)
21:48:40 [manu-db]
manu-db (~msporny@digitalbazaar.com) has joined #dig
22:26:31 [rszeno1]
rszeno1 (~rszeno@79.114.107.78) has joined #dig
22:28:53 [rszeno1]
rszeno1 has quit (Read error: Connection reset by peer)
22:29:37 [manu-db]
manu-db has quit (Ping timeout: 248 seconds)
22:29:38 [rszeno]
rszeno has quit (Ping timeout: 248 seconds)
22:29:51 [rszeno]
rszeno (~rszeno@79.114.107.78) has joined #dig
22:30:08 [dsheets]
dsheets has quit (Ping timeout: 240 seconds)
22:33:28 [dsheets]
dsheets (~Adium@c-71-198-141-58.hsd1.ca.comcast.net) has joined #dig
22:34:08 [mattl]
mattl has quit (Ping timeout: 240 seconds)
22:34:15 [mattl]
mattl (mattl@gateway/shell/gnu/x-gujbdmevocevcudo) has joined #dig
22:34:39 [mattl]
mattl is now known as Guest18997
22:36:36 [manu-db]
manu-db (~msporny@digitalbazaar.com) has joined #dig
22:37:45 [dsheets]
dsheets has quit (Ping timeout: 250 seconds)
22:51:10 [bblfish]
bblfish has quit (Read error: No route to host)
22:51:18 [bblfish_]
bblfish_ (~bblfish@AAubervilliers-651-1-325-4.w83-200.abo.wanadoo.fr) has joined #dig
22:56:06 [bblfish_]
bblfish_ has quit (Remote host closed the connection)
23:28:38 [melvster1]
melvster1 has quit (Ping timeout: 245 seconds)