00:14:12 <scor> scor has quit (Quit: scor)
00:29:27 <bblfish> bblfish has quit (Read error: Connection reset by peer)
00:30:02 <bblfish> bblfish (~bblfish@AAubervilliers-651-1-127-44.w86-198.abo.wanadoo.fr) has joined #dig
01:29:18 <presbrey> presbrey has quit (Quit: Terminated with extreme prejudice - dircproxy 1.2.0)
01:32:30 <scor> scor (~scor@c-98-216-97-72.hsd1.ma.comcast.net) has joined #dig
01:32:30 <scor> scor has quit (Changing host)
01:32:30 <scor> scor (~scor@drupal.org/user/52142/view) has joined #dig
02:22:13 <presbrey> presbrey (~presbrey@2001:4830:2446:b5:aede:48ff:fe00:6001) has joined #dig
02:44:19 <bblfish> bblfish has quit (Read error: Connection reset by peer)
02:44:55 <bblfish> bblfish (~bblfish@AAubervilliers-651-1-127-44.w86-198.abo.wanadoo.fr) has joined #dig
03:40:05 <scor> scor has quit (Quit: scor)
05:03:03 <Pipian> Pipian (~pipian@static-mum-59.181.115.17.mtnl.net.in) has joined #dig
07:12:33 <Pipian_> Pipian_ (~pipian@static-mum-59.181.115.17.mtnl.net.in) has joined #dig
07:12:33 <Pipian> Pipian has quit (Read error: Connection reset by peer)
07:12:34 <Pipian_> Pipian_ is now known as Pipian
07:15:01 <melvster> melvster (~melvin@p5797F363.dip.t-dialin.net) has joined #dig
07:32:43 <rszeno> rszeno (~rszeno@79.114.102.131) has joined #dig
07:37:19 <melvster> melvster has quit (Remote host closed the connection)
07:37:48 <melvster> melvster (~melvin@p5797F363.dip.t-dialin.net) has joined #dig
07:58:12 <deiu> deiu (~andrei@unaffiliated/deiu) has joined #dig
09:10:45 <presbrey> presbrey has quit (Ping timeout: 240 seconds)
09:10:52 <betehess> betehess has quit (Ping timeout: 245 seconds)
09:11:17 <betehess> betehess (~betehess@2001:470:8b2d:804:1d4e:3963:99ee:e9d3) has joined #dig
09:12:29 <presbrey> presbrey (~presbrey@2001:4830:2446:b5:aede:48ff:fe00:6001) has joined #dig
10:14:49 <cheater__> cheater__ has quit (Ping timeout: 246 seconds)
10:28:16 <cheater__> cheater__ (~cheater@g230227254.adsl.alicedsl.de) has joined #dig
10:32:52 <Pipian> Pipian has quit (Ping timeout: 248 seconds)
10:48:00 <Pipian> Pipian (~pipian@static-mum-59.181.115.17.mtnl.net.in) has joined #dig
10:48:00 <Pipian> Pipian has quit (Client Quit)
11:19:41 <trueg> trueg (~trueg@dslb-094-217-041-120.pools.arcor-ip.net) has joined #dig
11:22:14 <RalphS> RalphS (Ralph@w3cdhcp61.w3.org) has joined #dig
11:46:43 <melvster1> melvster1 (~melvin@p4FF96E37.dip.t-dialin.net) has joined #dig
11:48:06 <melvster> melvster has quit (Ping timeout: 264 seconds)
12:53:47 <t4nk286> t4nk286 (a103012a@gateway/web/freenode/ip.161.3.1.42) has joined #dig
12:55:08 <bblfish> hi
12:56:38 <t4nk286> hi, i have a question about rdflib.js.
12:56:48 <t4nk286> t4nk286 has quit (Client Quit)
12:57:11 <rblin> rblin (a103012a@gateway/web/freenode/ip.161.3.1.42) has joined #dig
12:57:28 <rblin>  is it possible in  rdflib to fetch remote graphs in parallel?
12:57:37 <rblin> what method do I call?
13:00:11 <bblfish> rblin, I think presbrey or melvster1 are those who know most about this lib. Perhaps it is also worth asking that question on github as a bug report
13:00:43 <bblfish> with explanation of where you are seeing the problem
13:00:52 <RalphS> RalphS has quit (Ping timeout: 265 seconds)
13:01:26 <RalphS> RalphS (Ralph@30-7-118.wireless.csail.mit.edu) has joined #dig
13:04:13 <rblin> I try to make a loop on all foaf knows of one foaf profile but when i want to check if all foaf:knows are loading i have only the last foaf knows loaded.
13:05:42 <bblfish> what method are you calling?
13:07:59 <rblin> fetch.nowOrWhenFetched()
13:09:23 <bblfish> did you check with Wireshark if the connections were being made?
13:10:00 <bblfish> I am not sure if rdflib can do fetches in parallel, or more than one at a time, or if one needs to create different fetch objects.... 
13:11:51 <rblin> yes I check it with wireshark and when i want to load 5 foaf at the same time i have 5 HTTP GET in my wireshark console
13:12:18 <bblfish> those GETs are going on in parallel?
13:13:55 <rblin> GETs are launch successivly in a loop. 
13:15:05 <bblfish> so you do something like for (url <- friends) { fetch.nowOrWhenFetched( function() {  do something with result }  ) }
13:15:07 <bblfish> ?
13:15:35 <bblfish> (can't remember the exact method calls)
13:15:57 <bblfish> perhaps fetch(url).nowOrWhenFetched(...)
13:17:00 <rblin> yes 
13:18:24 <bblfish> and you see wireshark downloading these in parallel?
13:20:00 <rblin> yes :)
13:22:35 <bblfish> ok, so I think then it's your client code that is overwriting the graphs perhaps, or that is now able to use the information
13:22:51 <bblfish> I would create a hashmap URL=>Graph for each downloaded graph
13:41:46 <bblfish> there are a lot of good examples at https://github.com/linkeddata/rdflib.js/blob/master/test/
13:42:09 <bblfish> but it is true that some good documentation would be helpful, to know what methods are available on a graph
13:42:12 <bblfish> graph.size?
13:43:03 <rblin> no
13:48:00 <scor> scor (~scor@w0107748.mgh.harvard.edu) has joined #dig
13:48:00 <scor> scor has quit (Changing host)
13:48:00 <scor> scor (~scor@drupal.org/user/52142/view) has joined #dig
13:48:30 <amy> amy (~amy@30-6-207.wireless.csail.mit.edu) has joined #dig
13:51:10 <bblfish> there must be a way to iterate through the graph in the mean time, so you can find out its size.... perhaps graph.length
14:25:51 <bblfish_> bblfish_ (~bblfish@ALagny-551-1-140-22.w92-141.abo.wanadoo.fr) has joined #dig
14:27:24 <bblfish> bblfish has quit (Ping timeout: 250 seconds)
14:58:28 <deiu> bblfish_, are you going to start the teleconf yourself?
14:59:31 <bblfish> bblfish (~bblfish@AAubervilliers-651-1-127-44.w86-198.abo.wanadoo.fr) has joined #dig
15:02:11 <bblfish_> bblfish_ has quit (Ping timeout: 246 seconds)
15:29:35 <rblin> rblin has quit (Ping timeout: 245 seconds)
16:20:27 <danbri> danbri has quit (Remote host closed the connection)
16:25:16 <danbri> danbri (~danbri@cable-146-255-148-108.dynamic.telemach.ba) has joined #dig
16:34:52 <danbri_> danbri_ (~danbri@cable-146-255-150-74.dynamic.telemach.ba) has joined #dig
16:35:35 <danbri__> danbri__ (~danbri@cable-146-255-148-108.dynamic.telemach.ba) has joined #dig
16:38:39 <danbri> danbri has quit (Ping timeout: 244 seconds)
16:39:41 <danbri_> danbri_ has quit (Ping timeout: 244 seconds)
16:45:04 <trueg> trueg is now known as trueg_away
16:48:30 <trueg_away> trueg_away is now known as trueg
17:12:14 <deiu> deiu has quit (Ping timeout: 244 seconds)
17:21:51 <trueg> trueg is now known as trueg_away
18:31:54 <betehess_> betehess_ (~betehess@31-35-216.wireless.csail.mit.edu) has joined #dig
18:32:41 <betehess_> betehess_ has quit (Client Quit)
18:38:00 <timbl> timbl (~timbl@93-62-235-11.ip24.fastwebnet.it) has joined #dig
19:22:23 <timbl> timbl has quit (Quit: timbl)
19:28:28 <melvster> melvster (~melvin@p4FF96242.dip.t-dialin.net) has joined #dig
19:29:57 <melvster1> melvster1 has quit (Ping timeout: 265 seconds)
19:50:13 <manu1> manu1 has quit (Ping timeout: 246 seconds)
20:01:07 <bblfish> bertails, hi! 
20:01:58 <bblfish> from time to time we should sync up so we know where we are going :-) betehess
20:04:56 <manu1> manu1 (~chatzilla@pool-96-240-166-105.ronkva.east.verizon.net) has joined #dig
20:07:51 <danbri> danbri (~danbri@cable-146-255-150-74.dynamic.telemach.ba) has joined #dig
20:09:49 <danbri__> danbri__ has quit (Ping timeout: 246 seconds)
20:19:55 <RalphS> RalphS has quit ()
20:32:14 <kennyluck> kennyluck has quit (Ping timeout: 246 seconds)
20:41:09 <kennyluck> kennyluck (~kennyluck@114-43-117-27.dynamic.hinet.net) has joined #dig
20:47:11 <trueg_away> trueg_away is now known as trueg
20:48:42 <trueg> trueg has quit ()
20:55:44 <danbri> danbri has quit (Remote host closed the connection)
21:06:43 <bblfish> $35000 WebID challenge http://www.healthdata.gov/blog/platform-challenge-1-simplified-sign
21:09:00 <betehess> bblfish: there is no need for a default graph
21:09:58 <bblfish> where do you put the information that links a graph to its metadata?
21:10:06 <betehess> wherever you want
21:10:15 <bblfish> well why not call that the default graph
21:10:25 <betehess> because it does not make sense
21:10:30 <betehess> for example
21:10:49 <betehess> I see where you're going, so let me explain that
21:11:38 <betehess> case 1: everything is on the file system. every graph is in its own file on the disk, let's say base-dir/foo/bar/baz.ttl
21:12:10 <betehess> the server can follow this convention: the metadata is available at base-dir/foo/bar/baz.meta.ttl
21:12:13 <betehess> done
21:12:18 <betehess> now case 2
21:12:32 <betehess> everything is in an rdf store
21:12:54 <betehess> solution 1: you do the same as in case one, but with the rdf store
21:13:25 <betehess> solution 2: you use one mega graph to hold all the metadata, and you call it something like "ldp:my-default-graph"
21:13:36 <betehess> which is not meant to be exposed by the LDP server
21:13:48 <betehess> again, it's an implementation detail
21:14:48 <betehess> the client only knows that if it wants to "know more" about the graph that it is GETting, it just needs to follow the Link header
21:15:02 <bblfish> how do you get the list of all graphs in teh store currently?
21:15:17 <bblfish> I think that's part of the AP'I I suppose
21:15:21 <betehess> why do you need it?
21:15:46 <bblfish> Well maintenance of graphs, know how much memory I am using, things like that
21:16:23 <betehess> so you want to centralize the data somewhere
21:16:37 <betehess> think about that: does Apache needs to know that?
21:16:47 <betehess> still, it can serve files
21:16:51 <betehess> that's the same
21:17:03 <bblfish> who is using the graphstore api?
21:17:35 <bblfish> that agent would want to know these things...
21:18:01 <bblfish> I just think there is an interpretation of default graphs where it makes sense
21:18:09 <betehess> ok, let me comment there
21:18:26 <bblfish> ( the union of all graphs certainly is stupid )
21:18:45 <betehess> first of all, do you agree that you could choose whatever graph to hold this kind of information?
21:18:57 <betehess> instead of the default one?
21:19:34 <betehess> then, what you want is a way to answer questions like: how many graph do I have
21:19:38 <bblfish> the problem with any graph, is that then you have a problem finding out which one it is
21:19:46 <bblfish> you are asking the store to know its name
21:20:03 <betehess> sesame and jena offers that in their api, so you should not have to maintain it yourself
21:20:07 <bblfish> it's like I should be albe to talk to you even when you don't remember your name :-)
21:20:17 <betehess> also, think about a purely file-based implementation, like Apache
21:20:32 <bblfish> apache has metadata too: it's the file system
21:20:35 <betehess> having centralized data for that would make it more difficult to scale on different server
21:20:43 <bblfish> and apache has config files
21:20:58 <bblfish> I don't see why you call it centralised
21:21:08 <betehess> guess what, when you access the file system, you iterate over all the files to get the information. there is a cost
21:21:13 <betehess> that's explicit
21:21:22 <betehess> there is no centralized index
21:21:30 <betehess> which is very important
21:21:48 <bblfish> but the data store itself knows a lot about its contents, no?
21:21:59 <betehess> not necesseraly
21:22:10 <bblfish> well it should know what contents it has
21:22:12 <betehess> only if you add this constraint in the api
21:22:19 <betehess> depends
21:22:44 <betehess> making that mandatory in the main interface would be a huge mistake
21:22:57 <betehess> you could impose another typeclass for it
21:23:10 <betehess> but even that, I'm not sure that you really need it
21:23:27 <betehess> at least, don't impose yourself to have to maintain this kind of metadata
21:23:30 <bblfish> you can always create a named graph as you say to put that info
21:23:41 <betehess> but you'll have to maintain it
21:23:47 <betehess> in a very centralized way
21:24:00 <bblfish> but I think on startup an amin needs to be able to ask queries even when the admin does not know what graph is the name of the default graph
21:24:03 <betehess> or, you may want to get something that iterates over the existing graphs
21:24:27 <bblfish> the way you are doing things you are going to make the admin's job debend on knweldge of an external resource. You can't bootstrap the thing
21:24:29 <betehess> don't understand your last comment
21:24:38 <betehess> of course you can
21:24:51 <betehess> you tell the admin to "RTFM"
21:25:09 <bblfish> but each implemetnation is going to place the default graph elsewhere
21:25:23 <bblfish> it's like .
21:25:26 <bblfish> in the file system
21:25:31 <betehess> so what? you don't expose this information anyway
21:25:39 <betehess> it's server specific
21:25:51 <bblfish> yes, the server admin also needs to get going
21:25:52 <betehess> Apache does not tell you on what filesystem it's running
21:26:06 <betehess> sure, but that's implementation specific
21:26:08 <bblfish> but you know which file you start off looking for config info
21:26:22 <bblfish> default graph is just an indexical
21:26:28 <betehess> config is something totally different from the current discussion
21:26:38 <bblfish> it says give me the metadat store of the store 
21:26:47 <bblfish> even if I don't know what it is named
21:26:48 <betehess> that's *your* interpretation
21:26:50 <betehess> your convention
21:27:00 <bblfish> yes, what is wrong with it?
21:27:05 <betehess> people may have other plans for their default graph
21:27:14 <betehess> because you don't have to impose it
21:27:21 <betehess> that's just wrong and useless in this case
21:27:36 <betehess> it will never be exposed by LDP
21:28:21 <betehess> if you want to write a server that provides to the sysadmin this kind of information, why not, but you need to be aware of the implications
21:28:43 <bblfish> well I think we'll probably find out by using it 
21:28:51 <betehess> IMO, making that efficient though metadata that you would maintain is just plainly wrong
21:29:40 <betehess> try to think how you would do that 1. without centralized index 2. with a pure filesystem-based implementation
21:30:20 <bblfish> yes, ... I'll see how it works in practice. But I have a feeling that you may need the index. But I can't tell for sure. 
21:30:27 <betehess> and tell the sysadmin to do "man du", like with apache
21:30:29 <bblfish> As I say even in the file system you have the . notation
21:31:01 <betehess> if there is an index, we won't scale, and we'll actually make the administration more complicated
21:31:15 <betehess> think about why Apache is so loved by sysadmins...
21:31:59 <betehess> I don't understand re: in the file system you have the . notation
21:32:32 <bblfish> well I am thinking of the default graph as an indexical for the metadata
21:32:58 <betehess> so everytime someone is accessing the store, you need to block on the default graph to update it?????
21:32:59 <bblfish> Also the other thing I am looking at is how this compares to N3 which has a main graph that cotnains graphs
21:33:18 <bblfish> ah ok
21:33:25 <bblfish> that's what you mean
21:33:36 <betehess> that's just a consequence
21:34:00 <betehess> and I know that you don't like the word "block"
21:34:01 <betehess> :-)
21:34:10 <bblfish> well we have a lot of blocking things in there
21:34:17 <bblfish> we should really rewrite all of it
21:34:23 <betehess> like what?
21:34:34 <bblfish> is sesame and jena not blocking?
21:34:44 <bblfish> the parsers are blocking mostly
21:34:47 <betehess> in the current naive implementation, maybe, but not in the future
21:34:53 <bblfish> :-)
21:35:04 <betehess> the interface is fine re: store
21:35:08 <bblfish> ok. Still do you think that 
21:35:23 <bblfish> null.instanceOf[URI] is really a good idea?
21:35:26 <betehess> no
21:35:41 <betehess> if we *have to*, it would be store.getDefaultGraph()
21:35:45 <bblfish> ah ok
21:35:48 <betehess> but as we won't do it, don't worry
21:36:09 <bblfish> well Pat Hayes presentation is quite interesting btw
21:36:15 <betehess> I know
21:36:26 <bblfish> anyway... I am writing a CORS proxy right now
21:36:33 <betehess> but that's not that relevant until Pat changes everything in RDF and SPARQL
21:36:56 <bblfish> was my checking ok?
21:37:03 <betehess> checking?
21:37:08 <bblfish> check-in
21:37:13 <betehess> the last one?
21:37:17 <betehess> I hope so :-)
21:37:36 <bblfish> ah ok, so you have had no problems yet
21:37:44 <betehess> I've been working on a RecordBinder
21:37:47 <betehess> not ready yet
21:37:55 <bblfish> the Sesame issue is odd because I added some simple tests and those work 
21:37:56 <betehess> I've not synchronized yet
21:38:14 <bblfish> what was the library you metnioned for doiong closing of sockets?
21:39:16 <bblfish> last week, when you looked at Sesame
21:39:19 <betehess> hrmmm
21:39:28 <betehess> scala-arm I believe
21:39:40 <betehess> from Josh Suerueth
21:39:54 <bblfish> ah found the notes
21:40:16 <bblfish> yes http://jsuereth.com/scala-arm/usage.html
21:40:35 <bblfish> I think un-jon was thinking or asking about transactions
21:40:56 <bblfish> thinking abut implementing transactions with his monadic contexts
21:41:37 <betehess> why not
21:41:47 <betehess> I'm waiting for a demonstration of the value
21:42:07 <betehess> also, if we support only one context, this would be useless
21:42:08 <bblfish> ok. Good, if monadic contexts help transactions then that seems like it would add value 
21:42:22 <betehess> maybe
21:42:33 <bblfish> all to be seen
21:42:58 <bblfish> I find it more useful to start with real world problems and then to move to change stuff
21:42:58 <betehess> monads would make explicit the fact that we only need the sequence
21:43:37 <bblfish> I was thinking in discussion with un-jon that perhaps
21:43:44 <bblfish> the graph object should be
21:43:46 <bblfish> mutable
21:43:56 <bblfish> or rather there should be mutable and immutable 
21:44:02 <bblfish> like in scala collections
21:44:19 <betehess> that would be ok
21:44:20 <bblfish> ( just an idea ). The reason being that sesaem and jena are mutable
21:44:24 <betehess> yes
21:44:34 <betehess> that would be fine
21:44:38 <bblfish> of course a good implemetnation would use non-mutable data structures
21:44:44 <bblfish> ah ok good :-)
21:44:45 <betehess> yes
21:44:57 <betehess> well, as long as you don't mess with the types, it's fine
21:45:27 <betehess> also, make sure that you make defensive copies when going from mutable to immutable
21:45:39 <bblfish> For the moment I don't need it. But I can see that one could. It would be nice to have real immutable graphs that don't do a whole copy (ie are efficeint)
21:45:41 <betehess> same the other way actually...
21:45:53 <betehess> well, we need it with Diesel
21:46:08 <betehess> diesel is O(n**2) because of that
21:46:13 <bblfish>  ah ok.
21:46:28 <betehess> as it uses graph union
21:46:30 <bblfish> +1 then for that
21:46:54 <bblfish> Ok. run out of ideas I think
21:46:55 <betehess> well, it works for now, so let's wait until we have real performance issue
21:47:19 <bblfish> yes I should present myself on the Linked Data Platform working group soon
21:47:23 <betehess> "n" is never big with Diesel
21:47:39 <betehess> can you join it through the Apache Foundation?
21:47:46 <bblfish> I am already in
21:47:48 <betehess> k
21:47:53 <bblfish> just have not had time to say hello
21:48:06 <bblfish> WG means I'll have to do some work
21:48:46 <bblfish> should have CORS working soon, and the RWW should be going too. 
21:49:22 <bblfish> well thanks for the feedback :-)
21:50:09 <bblfish> DIGlogger: pointer?
21:50:09 <bblfish> See http://dig.csail.mit.edu/irc/dig/2012-07-03#T21-50-09
21:50:53 <betehess> sure
21:50:54 <bblfish> we need to get this working for Lyon in October
21:50:58 <betehess> yes
21:51:02 <bblfish> :-)
21:51:03 <betehess> I should be there btw
21:51:31 <bblfish> oh and for Chaos Communication Congress in december, with Tor
21:51:49 <betehess> hrmmm, now I need to do a foldLeft on a HList #shapeless
21:52:07 <bblfish> un-jon showed how one could do webid over Tor competitor i2p
21:52:17 <betehess> wow, nice
21:52:17 <bblfish> well linked data over i2p
21:52:27 <betehess> that is nice
21:52:37 <betehess> can't wait to see
21:52:40 <bblfish> one could have linked data over i2p and tor and normal web. That would be really cool :-)
21:53:14 <betehess> does he have some writings about that already?
21:53:47 <bblfish> he just got i2p working on his computer published a foaf file in the .i2p url
21:54:21 <bblfish> you have things like
21:54:38 <bblfish> http://sdfsdfsdfsdf.onion/betehess/foaf.n3
21:54:55 <bblfish> or http://ssdfsdfsdfs.i2p/bblfish/foaf.rdf
21:55:14 <betehess> as the webid?
21:55:16 <bblfish> sdss... are cryptokeys that identify the machine in a distributed has table
21:55:20 <bblfish> yes
21:55:22 <betehess> oh
21:55:24 <betehess> I see
21:55:31 <bblfish> well with #me at the end or soemthing
21:55:47 <bblfish> so you can do linked data over those
21:55:52 <betehess> but this is not considered as anonymous, isn't it?
21:55:53 <bblfish> then you can do tls auth over them too
21:56:20 <bblfish> well if you wanted to be clever you'd of course not put such an obvious url
21:56:35 <betehess> you could even have one-time webid
21:56:40 <bblfish> not /bethess/foaf.n3 but perhaps /btls/#me
21:56:59 <betehess> k
21:57:01 <bblfish> the important thing about these networks is that people don't know where your machine is
21:57:16 <bblfish> so they don't know where you are 
21:57:37 <bblfish> and you could just show people who don't know you a public key
21:57:45 <bblfish> and to your friends have a link to a full profile
21:58:04 <bblfish> plus you don't need TLS server auth
21:58:16 <bblfish> because the server is dientified cryptographically
21:58:18 <betehess> that sounds wonderful
21:58:37 <bblfish> yes, just need to try it out to see hwo it works out :-)
22:03:25 <scor> scor has quit (Quit: scor)
22:30:05 <danbri> danbri (~danbri@cable-146-255-148-108.dynamic.telemach.ba) has joined #dig
22:33:40 <danbri> danbri has quit (Remote host closed the connection)
22:53:20 <melvster> melvster has quit (Ping timeout: 252 seconds)
23:09:49 <bblfish> bblfish has quit (Read error: Connection reset by peer)
23:10:25 <bblfish> bblfish (~bblfish@AAubervilliers-651-1-127-44.w86-198.abo.wanadoo.fr) has joined #dig
23:20:49 <amy> amy has left #dig