IRC log of dig on 2012-06-20

Timestamps are in UTC.

00:35:04 [timbl]
timbl (~timbl@209.117.47.251) has joined #dig
01:03:08 [timbl]
timbl has quit (Quit: timbl)
01:37:38 [timbl]
timbl (~timbl@dsl093-187-154.nyc1.dsl.speakeasy.net) has joined #dig
01:51:26 [timbl]
timbl has quit (Quit: timbl)
01:56:12 [timbl]
timbl (~timbl@dsl093-187-154.nyc1.dsl.speakeasy.net) has joined #dig
02:05:29 [timbl]
timbl has quit (Quit: timbl)
03:01:30 [rszeno]
rszeno (~rszeno@86.125.230.171) has joined #dig
04:17:46 [danbri]
danbri has quit (Remote host closed the connection)
08:07:06 [melvster]
melvster (~melvin@p4FF97546.dip.t-dialin.net) has joined #dig
08:12:09 [deiu]
deiu (~andrei@unaffiliated/deiu) has joined #dig
08:15:02 [bblfish_]
bblfish_ has quit (Ping timeout: 246 seconds)
08:18:43 [bblfish]
bblfish (~bblfish@AAubervilliers-651-1-217-120.w86-198.abo.wanadoo.fr) has joined #dig
08:25:07 [bblfish_]
bblfish_ (~bblfish@AAubervilliers-651-1-262-15.w86-212.abo.wanadoo.fr) has joined #dig
08:25:31 [bblfish]
bblfish has quit (Ping timeout: 276 seconds)
10:14:02 [cheater__]
cheater__ has quit (Ping timeout: 246 seconds)
10:42:21 [bblfish]
bblfish (~bblfish@AAubervilliers-651-1-332-109.w83-114.abo.wanadoo.fr) has joined #dig
10:42:26 [bblfish_]
bblfish_ has quit (Ping timeout: 255 seconds)
11:10:38 [melvster]
melvster has quit (Remote host closed the connection)
11:12:47 [melvster]
melvster (~melvin@p4FF97546.dip.t-dialin.net) has joined #dig
11:36:41 [RalphS]
RalphS (Ralph@30-7-118.wireless.csail.mit.edu) has joined #dig
12:09:18 [bblfish_]
bblfish_ (~bblfish@AAubervilliers-651-1-61-156.w83-200.abo.wanadoo.fr) has joined #dig
12:09:32 [bblfish]
bblfish has quit (Ping timeout: 246 seconds)
12:15:38 [rszeno]
rszeno has quit (Quit: Leaving.)
12:21:13 [bblfish_]
betehess: just answered some of your questions on the commit and pull request https://github.com/w3c/banana-rdf/pull/5
12:21:17 [bblfish_]
bblfish_ is now known as bblfish
12:21:48 [bblfish]
damn, just now saw your note that you had included the Solution(s) stuff...
12:21:53 [betehess]
bblfish: have you seen the commits I've made yesterday? (especially the latest ones)
12:21:58 [betehess]
yep
12:22:10 [bblfish]
I don't understand why I did not see that.
12:22:22 [betehess]
the interface was weird
12:22:47 [betehess]
I wanted to do a general comment, which worked, but it also told me that it couldn't do the merge automatically
12:22:57 [betehess]
so maybe there was a glitch
12:23:57 [bblfish]
well I am just new to reading github perhaps
12:26:47 [bblfish]
looks like I was going in the same direction ....
12:27:59 [betehess]
it's more like I followed you :-)
12:29:09 [bblfish]
danm CERN with those silly black holes they keep creating!
12:30:26 [danbri]
danbri (~danbri@cable-146-255-148-108.dynamic.telemach.ba) has joined #dig
12:34:27 [betehess]
huh, /me just updated the validator project with those changes: the tests can't keep up with the database (just moved to jena-tdb) which is just too fast now. we have to wait explicitly for the akka messages to be delivered :-)
12:39:39 [bblfish]
are you saying that jena-tdb is slow?
12:40:38 [RalphS]
RalphS has quit (Ping timeout: 240 seconds)
12:40:48 [RalphS]
RalphS (Ralph@w3cdhcp61.w3.org) has joined #dig
13:07:50 [bblfish_]
bblfish_ (~bblfish@AAubervilliers-651-1-266-151.w86-212.abo.wanadoo.fr) has joined #dig
13:08:38 [bblfish]
bblfish has quit (Ping timeout: 245 seconds)
13:20:23 [melvster]
bblfish ping?
13:20:48 [melvster]
bblfish_
13:20:50 [danbri_]
danbri_ (~danbri@cable-146-255-148-108.dynamic.telemach.ba) has joined #dig
13:21:01 [bblfish_]
yes?
13:21:05 [bblfish_]
bblfish_ is now known as bblfish
13:21:26 [melvster]
is this interesting to you? http://blog.iandavis.com/2012/05/23/5-weeks-of-go/
13:21:38 [melvster]
you know ian davis is working on a game?
13:21:52 [danbri]
danbri has quit (Read error: No route to host)
13:25:01 [bblfish]
another language... sounds interesting I suppose... One can't follow them all
13:26:39 [melvster]
oh wait sorry of course you use play ... i got mixed up between go and play :)
13:28:38 [bblfish]
? ah
13:28:48 [bblfish]
Go is a game too, which I do play
13:28:56 [bblfish]
;-)
13:29:04 [melvster]
lo
13:29:06 [melvster]
lol
13:40:02 [betehess]
bblfish, I'm starting work on using support in the Jena implementation http://jena.apache.org/documentation/tdb/tdb_transactions.html
13:40:30 [mattl]
we need semweb space invaders ;)
13:40:31 [betehess]
s/support/transaction/
13:40:57 [bblfish]
ah ok
13:41:05 [bblfish]
I am just trying to merge your previous work...
13:41:42 [bblfish]
transaction support sounds good
13:42:26 [betehess]
also, I'll add support for canceling queries
13:42:43 [betehess]
for the asyn implementation
13:42:48 [betehess]
async
13:43:14 [betehess]
that should be automatic if there is a timeout in akka
13:43:22 [betehess]
not the case today
13:43:24 [bblfish]
yes, sounds good
13:43:32 [bblfish]
when are you doing your presentation?
13:43:57 [betehess]
first one today to my boss, then tomorrow
13:44:16 [betehess]
that's fine, I'm very productive these days
13:45:03 [bblfish]
it's getting to be very powerful
13:51:27 [danbri_]
danbri_ has quit (Read error: Connection reset by peer)
13:57:43 [danbri]
danbri (~danbri@cable-146-255-148-108.dynamic.telemach.ba) has joined #dig
14:04:04 [betehess_]
betehess_ (~betehess@31-35-223.wireless.csail.mit.edu) has joined #dig
14:04:12 [betehess_]
betehess_ has quit (Remote host closed the connection)
14:12:48 [RalphS]
RalphS has quit (Ping timeout: 245 seconds)
14:13:05 [RalphS]
RalphS (Ralph@30-7-118.wireless.csail.mit.edu) has joined #dig
14:15:10 [rszeno]
rszeno (~rszeno@79.114.105.203) has joined #dig
14:34:58 [deiu]
this way a caching engine can refresh the cache from WebID protected locations even when you're not around to do it yourself :)
14:40:49 [melvster]
wow
14:49:08 [timbl]
timbl (~timbl@firewall.royalsociety.org) has joined #dig
15:36:12 [bblfish]
betehess: ok, I merged your work and added a few small improvements
15:36:32 [bblfish]
perhaps it' would be worth merging that pull request in soon, before everything gets lost again!
15:37:32 [bblfish]
(it was my fault of course not to check and get the latest version... )
15:41:40 [timbl]
timbl has quit (Quit: timbl)
15:44:13 [betehess]
bblfish, I still don't get what you're doing with RDFGraphQuery
15:44:26 [betehess]
the typeclass does not need to know about the underlying instance
15:44:36 [bblfish]
I am just allowing the graph to be queried a number of times
15:45:01 [betehess]
you can always keep the instance of your typeclass
15:45:09 [betehess]
so there is no need for that
15:45:35 [bblfish]
well if you do query(graph,query), then the underying object is always reconstructing the query object
15:45:36 [betehess]
take the of an RDFStore: you don't instanciate a new one every call!
15:45:58 [betehess]
then don't implement this interface in the case of sesame
15:46:29 [betehess]
if there is a cost that you don't want to assume, then don't make it available
15:46:54 [bblfish]
is it cost-free in Jena?
15:46:58 [betehess]
yeah
15:47:05 [bblfish]
in Sesame you have to copy all the triples into a store
15:47:21 [betehess]
yes
15:47:35 [bblfish]
the way I wrote it you get it cost free for both
15:47:41 [betehess]
why do you need to use this API?
15:47:59 [betehess]
you're not implementing the right interface!
15:48:01 [bblfish]
well on the read-write-web we were currently reading the graph from the file
15:48:08 [betehess]
there is *already* SPARQLEngine
15:48:37 [bblfish]
yes, this was just to make it easier and more natural to query a graph
15:48:38 [betehess]
so you have a graph. do you *really* need to do another query on it?
15:48:48 [betehess]
Diesel is all about traversing the graph
15:48:59 [betehess]
it's a lot easier than using sparql again
15:49:11 [betehess]
you should use Diesel, not another sparql query
15:49:35 [bblfish]
I suppose I don't need it for my use case here, as that is a one time query
15:49:42 [bblfish]
ah no
15:49:49 [bblfish]
I have an agent with a graph in memory
15:49:51 [betehess]
anyway, you have SPARQLEngin
15:49:53 [betehess]
e
15:49:58 [bblfish]
and it can receive queries from the web
15:50:15 [bblfish]
so the object allows that to be queried as long as the graph has not be changed
15:50:19 [betehess]
fine, make it a SPARQLEngine
15:50:28 [betehess]
not an RDFGraphQuery
15:50:34 [bblfish]
well that was an idea too...
15:50:44 [betehess]
I'm just saying that this interface does not really make sense
15:51:06 [bblfish]
let me look at it again
15:51:22 [betehess]
the def makes it too restrictive and there is already SPARQLEngine that does the same job
15:51:57 [bblfish]
yes, but if you have a graph, then it's easier to construct the RDFGraphQuery(graph)
15:51:58 [betehess]
hint: your client code that uses RDFGraphQuery probably does not care about the graph instance that is inside
15:52:49 [betehess]
just support the interface
15:53:17 [bblfish]
well at present I was reading a graph from the hard drive like in unfiltered read-write-web
15:53:22 [betehess]
sure
15:53:30 [bblfish]
then I wrapeed it. But I can also put it in a sparql engine
15:53:37 [betehess]
but after you have put it in your wrapper, you don't care about the graph
15:53:53 [betehess]
you care about being able to query it with sparql
15:53:55 [betehess]
that's all
15:54:00 [bblfish]
not that much I think. I suppose if someone sends an update
15:54:03 [betehess]
that's already SPARQLEngine
15:54:09 [betehess]
ha haaa
15:54:19 [betehess]
a graph is supposed to be immutable here
15:54:26 [betehess]
you're making a store
15:54:33 [betehess]
don't lie to your application :-)
15:55:06 [bblfish]
I had not gotten around to this. I could have created a new file for each change and given them different names - not sure how we should deal with versioning...
15:55:30 [betehess]
start with not allowing one to modify your graphs
15:55:38 [bblfish]
problem with graphstores is that they tend to try to save their data to disk I think
15:55:54 [bblfish]
in sesame at least
15:56:00 [betehess]
nope
15:56:14 [betehess]
there are in-memory store
15:56:27 [betehess]
they don't have to be persisted
15:56:30 [bblfish]
yes. (though you can save it to disk, if you give a directory name)
15:56:36 [betehess]
yes
15:57:04 [bblfish]
mhh we don't have update on the SPARQL-engine do we?
15:58:03 [bblfish]
oh well. I thought my trick was not too bad
15:58:33 [betehess]
yeah, I believe that we should not allow sparql update at all
15:58:51 [betehess]
we should implement that thought the PATCH we're gonna define in LDP WG
15:58:56 [betehess]
btw, you should join
15:59:11 [bblfish]
yes, I am there in LDP WG
15:59:20 [bblfish]
not have time to follow it yet
15:59:54 [bblfish]
still it would be nice to have UPDATE for the moment as a demo
16:00:05 [bblfish]
but I am not quite round to that
16:00:21 [bblfish]
mhh...
16:00:54 [betehess]
we should not allow sparql update on rdf graphs as they are immutable
16:01:05 [betehess]
or, your interface should return a new instance
16:01:21 [betehess]
too bad that neither jena nor sesame does that right...
16:01:22 [bblfish]
ah on rdf grpahs
16:01:25 [betehess]
yes
16:01:26 [bblfish]
what about on rdf stores?
16:01:43 [betehess]
we already have addNameGraph and stuff :-)
16:01:54 [betehess]
a store is meant to be modifiable
16:02:20 [bblfish]
well to do this right and efficiently one would need to use scala immutable Sets
16:03:01 [bblfish]
otherwise adding triples to sets or merging graphs gets very expensive
16:03:32 [bblfish]
ok, I did not know that Stores were meant to be modifiable
16:04:48 [bblfish]
So should I create 1 store for each file on the hard drive?
16:05:31 [bblfish]
The other option is 1 store for the whole server using sesame's or jena's persistent stores
16:05:40 [bblfish]
and just save files to the hard drive as caches
16:06:17 [bblfish]
then queries would be faster, as the jena store would indexed all the triples
16:08:51 [betehess]
plan b is definitely better
16:09:16 [betehess]
we could setup watchers in case file are modified directly by user
16:09:38 [bblfish]
mhh, yes thought so.
16:10:11 [bblfish]
but then how does akka come in useful - the idea of one actor per resource seems a bit expensive then
16:10:35 [betehess]
depends on the approach
16:10:58 [betehess]
maybe you want a set of stores
16:11:11 [betehess]
one for each rdf:container for example
16:11:27 [betehess]
maybe you want to organize them as a tree
16:11:32 [betehess]
maybe you want only one store
16:11:43 [bblfish]
true.
16:11:53 [betehess]
maybe you want to have one actor == one graph
16:11:54 [bblfish]
so there the store is the actor really, right?
16:12:00 [betehess]
yes
16:12:03 [betehess]
I mean
16:12:09 [betehess]
that's one possible implementation :-)
16:12:29 [bblfish]
yes. there are a lot of different ways to do this
16:12:33 [betehess]
where I choose to just put an RDFStore behind one actor
16:12:37 [betehess]
yes
16:13:00 [betehess]
IMO, you should start without generating the files on disk first
16:13:14 [betehess]
because that's only a matter of providing another implementation
16:13:46 [bblfish]
implementation of ?
16:14:19 [bblfish]
mhh, now I have to undo all that RDFGraph thing again...
16:18:18 [bblfish]
should just be a matter of undoing a patch
17:24:25 [bblfish]
betehess: ok, reverted that change
17:28:46 [bblfish]
( on the patch request 5)
17:55:34 [deiu]
deiu has quit (Ping timeout: 245 seconds)
18:15:25 [bblfish]
betehess: I am surprised this works https://github.com/w3c/banana-rdf/blob/master/rdf-test-suite/src/main/scala/DieselGraphExplorationTest.scala#L42
18:15:56 [bblfish]
It is quite accidental if it does, since you have 2 foaf:name relations and rdf is unordered
18:16:40 [betehess]
that's clearly wrong
18:16:47 [betehess]
thanks for spotting on
18:18:18 [betehess]
especially giving better informations in failures
18:18:58 [bblfish]
np, just spotted that showing diesel to the student in St Etienne
18:19:25 [betehess]
:-)
19:27:21 [cheater_]
cheater_ (~cheater@g229020134.adsl.alicedsl.de) has joined #dig
19:54:00 [betehess]
bblfish, some tests don't pass with Sesame
19:54:18 [bblfish]
yes, I thought you could ask your Sesame expert about that
19:54:25 [betehess]
SesameGraphQueryTest
19:54:29 [betehess]
?
19:54:34 [betehess]
I know nobody
19:54:34 [bblfish]
I know there was no test before then
19:54:39 [betehess]
ah
19:56:19 [bblfish]
I can look it up later, just now I am working a bit more on the writers
19:56:28 [bblfish]
I think the way Play2.0 has it is nearly correct
19:56:36 [bblfish]
they use type classes, btw
19:57:26 [bblfish]
( mind you there is some serious ugliness in their Writer code - wouild be easy to fix )
19:58:41 [bblfish]
see thread https://groups.google.com/d/topic/play-framework/XtPGZ22VZ08/discussion
20:05:05 [betehess]
looks like you really don't want to have typeclasses for the mimetypes
20:05:52 [betehess]
and I still don't see why you keep calling Turtle, N3, etc. "languages"
20:05:58 [betehess]
RDF language?
20:06:08 [betehess]
that's not what google says
20:06:28 [betehess]
RDFSerialization is just fine I believe
20:06:33 [betehess]
anything else would be confusing
20:07:45 [bblfish]
David Lewis in Language and Languages defines a Language as a vocabulary + grammar + semantics (if I remember correctly)
20:07:57 [bblfish]
I can check it quickly if you want
20:08:33 [bblfish]
URIs are our vocabulary, rdf/xml is one syntax, turtle another, ...
20:08:46 [bblfish]
and URIs come with their semantics
20:09:09 [bblfish]
also a serialisation is a process
20:09:23 [bblfish]
usually from java to bytes
20:09:30 [betehess]
syntax would be ok
20:09:34 [bblfish]
there is a word for the opposite: deserialisation
20:09:39 [betehess]
still not a language per se
20:10:08 [betehess]
people head "serialization format" when we say "serialization"
20:10:12 [bblfish]
well perhaps Language is a bit too strong
20:10:22 [bblfish]
mime type is close to what it is
20:10:26 [bblfish]
:)
20:10:43 [bblfish]
but that's too technical
20:10:50 [bblfish]
xml is syntax
20:11:08 [betehess]
so are Turtle, N3, etc.
20:11:09 [bblfish]
atom is more than syntax, it comes with semantics
20:11:46 [bblfish]
well I am ok with syntax
20:12:11 [betehess]
my issue is that w3c defines RDF Syntax as being RDF/XML...
20:12:25 [betehess]
not my fault though
20:12:34 [bblfish]
no it can be turtle too http://www.w3.org/TR/turtle/
20:13:06 [bblfish]
"This document defines a textual syntax for RDF called Turtle" so Syntax seems good
20:13:41 [betehess]
ok for now
20:13:59 [bblfish]
what is? Syntax?
20:14:10 [bblfish]
SyntaxType
20:14:14 [betehess]
why don't writers have the type of the RDFSyntax being used?
20:14:43 [betehess]
it's a very valuable information
20:14:51 [betehess]
you can see it as a phantom type
20:14:57 [betehess]
still very important
20:15:09 [bblfish]
yes.
20:15:45 [bblfish]
the problem is that it means that each Language/Syntax/RDFSerlialisation had to have a class to go with it to put it in a category of some type
20:16:16 [bblfish]
And I think that is somewhat wrong headed. AS you have to decide what group things belong to in your class hierachy
20:16:33 [bblfish]
that would be ok in RDF as one can add new classes, but in scala it's a bit heavy
20:16:49 [bblfish]
but I must say I am not quite happy with that part of the solution.
20:16:57 [betehess]
use typeclasses!!!!!!!!
20:16:59 [bblfish]
I just needed new seriliisations/syntaxes
20:17:07 [betehess]
seriously
20:17:20 [betehess]
break the class hierarchy
20:17:24 [betehess]
just don't do that
20:17:28 [bblfish]
betehess: I was just reading up on that here http://stackoverflow.com/questions/11065487/play-2-0-restful-request-post-processing/11074923#11074923
20:18:02 [bblfish]
As I said I think the Play2.0 people have soemthing that should be close to what we want
20:18:07 [bblfish]
using type classes
20:18:22 [bblfish]
https://groups.google.com/d/topic/play-framework/XtPGZ22VZ08/discussion
20:18:29 [bblfish]
their Writers are close
20:19:01 [bblfish]
perhaps we should inspire ourselves from that
20:19:19 [betehess]
what you want is to be able to define a new RDF Syntax, and then define the Serializers/deserializers that goes with it
20:19:35 [betehess]
it's a simple typecalss
20:19:42 [betehess]
you don't need to know them in advance
20:19:44 [RalphS]
RalphS has quit ()
20:19:54 [betehess]
maybe I should hack that for you
20:20:07 [betehess]
in the case of the readers
20:21:28 [bblfish]
In that e-mail I wrote " My feeling is that the writeable should specify the content type of the returned serialisation. "
20:21:39 [betehess]
yes
20:22:30 [bblfish]
so one could do it like this case class Writeable[-A](transform: (A => Array[Byte]), contentType: ContentType)
20:24:02 [bblfish]
if you want to hack something just let me know :-) I was starting to think about it
20:25:31 [betehess]
SesameWriter could take the ops as a parameter
20:26:18 [bblfish]
betehess: INtelliJ tells me I don't
20:26:30 [betehess]
tells what?
20:26:40 [bblfish]
well that ops is never used
20:27:13 [betehess]
yeah, exposing is from the interface can clash with other things (especially when called ops)
20:27:29 [bblfish]
probably ended up there by mistake
20:27:33 [betehess]
I've been beaten by that before understanding it was a bad idea
20:27:35 [betehess]
k
20:28:04 [bblfish]
I'll remove it.
20:28:42 [betehess]
I believe that RDFReaderFactory#find is symptomatic of your need of a typeclass
20:29:40 [betehess]
instead, you want to say "give an RDFSyntax such that there exists a RDFReader[Rdf, RDFSyntax]] for it"
20:30:17 [betehess]
so, something like:
20:30:18 [betehess]
[[
20:30:31 [betehess]
object Turtle extends RDFSyntax {
20:31:07 [betehess]
implicit val turtlereader: RDFReader[Rdf, RDFSyntax]] = ...
20:31:10 [betehess]
]]
20:31:42 [betehess]
well, should be a def
20:32:00 [bblfish]
where Rdf is ?
20:32:03 [betehess]
implicit def turtlereader(implicit ops: ...): RDFReader[Rdf, Turtle]] = ...
20:32:30 [betehess]
implicit def turtlereader[Rdf <: RDF]: RDFReader[Rdf, Turtle]] = ...
20:32:32 [bblfish]
ah yes. like in scalaz
20:32:48 [betehess]
you may not need ops
20:32:50 [betehess]
depends
20:33:01 [betehess]
like a typeclass :-)
20:35:11 [bblfish]
thanks for reminding me of that piece there
20:35:48 [bblfish]
what would be nice would be to have something a bit more generic that RDFReader. It's a bit heavy
20:36:35 [betehess]
can you remind why in Language it's defined like that:
20:36:37 [betehess]
[[
20:36:38 [betehess]
def fromMime(mime: String): Option[Language]
20:36:39 [betehess]
]]
20:36:40 [betehess]
?
20:36:52 [betehess]
why not the following
20:37:12 [betehess]
val mimetypes: Set[String]
20:37:13 [betehess]
?
20:37:57 [betehess]
maybe I'm looking at the old version
20:38:03 [bblfish]
that's just because I did not have time
20:38:19 [bblfish]
did not want to go further, before chatting with you
20:38:21 [betehess]
ah ahh
20:38:23 [betehess]
it is old
20:38:33 [betehess]
oh
20:38:34 [betehess]
wait
20:38:42 [bblfish]
I don't think it should be a Set perhaps a List
20:38:52 [bblfish]
because there is always one that is the default
20:38:55 [bblfish]
IETF
20:39:11 [bblfish]
( then there are legacy ones )
20:39:35 [bblfish]
you see I had BlockingSparqlAnswerWriter
20:40:20 [betehess]
hrmmm, right, it may be enough to say that the first one would be the default, by convention
20:40:42 [bblfish]
on the other hand hash sets are searched faster
20:40:54 [bblfish]
defaultMime
20:41:06 [betehess]
BlockingSparqlAnswerWriter should not define the Language as a value :-)
20:41:16 [danbri_]
danbri_ (~danbri@cable-146-255-148-108.dynamic.telemach.ba) has joined #dig
20:41:23 [danbri]
danbri has quit (Read error: Connection reset by peer)
20:41:31 [betehess]
Answers <: Sparql#Solutions ?
20:41:37 [betehess]
is this really needed?
20:41:49 [bblfish]
I think that is an error
20:41:51 [betehess]
subtyping should do that for you
20:41:52 [betehess]
ok
20:42:17 [betehess]
also, s/BlockingSparqlAnswerWriter/SparqlSolutionsWriter/
20:42:36 [bblfish]
still it's blocking
20:42:44 [bblfish]
we want the short one to be for the async :-)
20:43:13 [betehess]
hrmmm
20:43:13 [bblfish]
But I think one should generify that right?
20:43:25 [betehess]
generify?
20:43:38 [bblfish]
A writer takes an Object => Array[Byte]
20:43:51 [betehess]
for the async version?
20:44:11 [bblfish]
well that's closer to the Play2.0 way... but even for the sync one, no?
20:44:28 [betehess]
if you find a nice way to express it, I'm ok
20:45:01 [betehess]
re: closing connections and iterators, you're right, there are mistakes there
20:45:12 [bblfish]
the problem is that RDF/Graphs take base string arguments
20:45:22 [betehess]
yeah
20:45:32 [betehess]
and that should be mandatory
20:45:41 [betehess]
not like in jena, grrrr
20:46:55 [bblfish]
on the other hand that is not needed for the SparqlSolutionWriter ( I think )
20:48:01 [betehess]
actually, what you want is more like a SparqlResultWriter
20:48:37 [betehess]
and you want a fold(SparqlResult)(Solutions => T, Graph => T, Boolean => T)
20:48:52 [betehess]
don't you?
20:49:26 [bblfish]
mhh
20:50:27 [bblfish]
why Results, rather than Solutions?
20:50:46 [betehess]
because Solutions == Rows
20:50:54 [betehess]
it's for SPARQL Select
20:50:58 [bblfish]
yes
20:51:09 [betehess]
but you want to support Construct and Ask
20:51:17 [bblfish]
true
20:52:12 [bblfish]
We don't have a type for a generic SparqlResult yet
20:52:15 [betehess]
re: scala-arm, I believe that we should not let people use iterable directly, but Managed ones
20:52:22 [bblfish]
I used Either3
20:52:22 [betehess]
that's the trick
20:52:36 [betehess]
yeah, we should abstract that as well
20:53:52 [bblfish]
ah yes, I see, that makes sense. Don't return the Sparql#Solution directly but wrap it in one of those arms
20:55:22 [betehess]
yes
20:55:26 [betehess]
hrmm
20:55:27 [betehess]
no
20:55:33 [betehess]
even better :-)
20:55:44 [betehess]
you still want to return the Solutions
20:56:07 [betehess]
then people need to call one of the functions to do something with it
20:56:11 [betehess]
currently, toIterable
20:56:26 [betehess]
that's where you can return the managed iterable
20:56:49 [betehess]
so client-side, people cannot use it without closing it :-)
20:56:53 [betehess]
that's evil
20:56:59 [betehess]
or not
20:57:11 [bblfish]
yes. that's nice
20:59:06 [betehess]
ok, /me needs to leave
20:59:30 [bblfish]
I think I'll go to bed
20:59:53 [bblfish]
I'll check in tmorrow first to see if you added something new :-)
21:05:27 [bblfish]
time for some Frank Zappa
21:44:37 [melvster]
melvster has quit (Ping timeout: 255 seconds)
21:58:42 [melvster]
melvster (~melvin@p4FF976DC.dip.t-dialin.net) has joined #dig
22:38:52 [un_jon]
un_jon (~androirc@37-8-188-74.coucou-networks.fr) has joined #dig
22:45:23 [un_jon]
un_jon has quit (Ping timeout: 255 seconds)