IRC log of dig on 2014-03-10
Timestamps are in UTC.
- 11:25:20 [DIGlogger]
- DIGlogger (~dig-logge@groups.csail.mit.edu) has joined #dig
- 11:25:20 [orwell.freenode.net]
- topic is: Decentralized Information Group @ MIT http://dig.csail.mit.edu/
- 11:25:20 [orwell.freenode.net]
- Users on #dig: DIGlogger RalphS jmvanel melvster Sebastien-L cheater_ ericP bblfish slvrbckt_ mattl Yudai presbrey sandro bergi daniel-smith
- 12:32:00 [Sebastien-L]
- Sebastien-L has quit (Ping timeout: 265 seconds)
- 12:41:06 [bblfish_]
- bblfish_ (~bblfish@AAubervilliers-651-1-232-137.w86-198.abo.wanadoo.fr) has joined #dig
- 12:43:07 [bblfish]
- bblfish has quit (Ping timeout: 265 seconds)
- 13:37:21 [deiu]
- deiu (~andrei@unaffiliated/deiu) has joined #dig
- 13:45:46 [amy]
- amy (~amy@31-34-29.wireless.csail.mit.edu) has joined #dig
- 13:51:09 [Sebastien-L]
- Sebastien-L (~sebastien@2a01:e35:8b47:7ab0:3cf1:7a29:4422:4806) has joined #dig
- 13:51:50 [betehess]
- betehess (~betehess@cpe-66-108-240-206.nyc.res.rr.com) has joined #dig
- 14:50:59 [Ralph]
- Ralph (rswick@w3cvpn1.w3.org) has joined #dig
- 14:52:36 [RalphS]
- RalphS has quit (Write error: Broken pipe)
- 14:58:19 [Pipian-Work]
- Pipian-Work (~Pipian@c-76-21-2-110.hsd1.ca.comcast.net) has joined #dig
- 15:26:53 [Pipian-Work]
- Pipian-Work has quit (Quit: Pipian-Work)
- 15:29:39 [Pipian-Work]
- Pipian-Work (~Pipian@c-76-21-2-110.hsd1.ca.comcast.net) has joined #dig
- 15:36:17 [bblfish_]
- bblfish_ is now known as bblfish
- 15:36:30 [bblfish]
- Hi betehess, are you here?
- 15:37:28 [betehess]
- heya
- 15:38:11 [bblfish]
- hi, are you working from NY?
- 15:38:23 [betehess]
- I am
- 15:39:25 [bblfish]
- Ah, ok. Just getting some traction on rww-play. a startup in the US may pay us for some consulting... we'll see...
- 15:39:49 [bblfish]
- Are you still working on banana-rdf from NY?
- 15:40:16 [betehess]
- I will
- 15:40:24 [betehess]
- I am still finishing my move here
- 15:40:37 [betehess]
- but lots of idea for banana-rdf
- 15:40:53 [bblfish]
- ah cool. Btw, if you go into flowdoc you'll find our latest BP
- 15:41:40 [bblfish]
- yes, we should slowly be getting up to the latest version (until now we were using a fork because I was using Plantain)
- 15:42:05 [betehess]
- Plantain should come back
- 15:42:58 [bblfish]
- ah cool. I thought we should have a mini banana too, for Scala-JS
- 15:46:05 [bblfish]
- ok, good to hear you're still on it :-)
- 15:49:06 [betehess]
- mini-banana :-)
- 15:49:22 [betehess]
- I guess that's what Plantain was meant to be
- 15:49:42 [betehess]
- there should be *no* dependency on jena/sesame from Plantain
- 15:49:50 [betehess]
- if there is, then it defeats the purpose
- 15:53:49 [Pipian-Work]
- Pipian-Work has quit (Quit: Pipian-Work)
- 16:00:20 [deiu]
- presbrey, sandro: I've fixed the Firefox issue re. WebID auth
- 16:32:58 [sandro]
- oh yeah??
- 16:41:59 [cheater_]
- cheater_ has quit (Ping timeout: 269 seconds)
- 17:17:10 [cheater]
- cheater (~cheater@ip-80-226-1-17.vodafone-net.de) has joined #dig
- 17:28:15 [bblfish]
- btw, there are some interesting developments on the TLS1.3/HTTP2.0 front http://lists.w3.org/Archives/Public/ietf-http-wg/2014JanMar/0908.html - that will take time to become available I suppose but it would fix a few remaining issues
- 17:30:53 [apinstein]
- apinstein (~apinstein@c-71-56-119-81.hsd1.ga.comcast.net) has joined #dig
- 17:37:02 [apinstein]
- apinstein has quit (Quit: apinstein)
- 17:54:03 [cheater]
- #-}
- 18:25:39 [bblfish]
- @betehess I thought of a name for a mini banana: Cavendish
- 18:32:28 [deiu]
- Hi
- 18:33:02 [deiu]
- Does anyone know if you can get the HTTP status code from rdflib.js's nowOrWhenFetched() ?
- 18:33:28 [deiu]
- or how do you treat exceptions when you dereference a bad URI?
- 18:35:55 [bblfish]
- You need to print out the thing. I think you need one fetcher for all your transactions, and it stores all the metadata about requests in a special graph...
- 18:36:24 [bblfish]
- btw, we need to add all the info there for all the ldp headers
- 18:37:43 [bblfish]
- also we made the nowOrWhenFetched a lot easier to use here: https://github.com/stample/rdflib-pg-extension
- 18:38:04 [bblfish]
- by wrapping it inside the notion of a PointedGraph
- 18:39:13 [deiu]
- I see
- 18:39:24 [deiu]
- thanks!
- 18:40:46 [bblfish]
- btw, I don't think we have yet done anything to look in that metadata graph.
- 18:41:37 [Sebastien-L]
- Sebastien-L has quit (Ping timeout: 245 seconds)
- 18:41:47 [bblfish]
- I just keep seeing it, and we'll need to use it. If you find out how, perhaps you could add a function to the PG library so that one can easily acceess that graph
- 18:42:25 [bblfish]
- something like pg.meta as a function to a pointedGraph, where the pointer is on the metadata
- 18:43:08 [deiu]
- Is the .fail() method part of main rdflib.js?
- 18:43:24 [bblfish]
- I need to also push a couple of fixes on rdflib.js
- 18:44:04 [bblfish]
- which fail method?
- 18:46:36 [deiu]
- the one you call after .fetch().then()
- 18:47:25 [bblfish]
- That is part of those Promise libraries I think
- 18:50:52 [bblfish]
- there is promise library and async library we use
- 18:51:35 [deiu]
- it's ok, I'll look up the triples in the graph
- 18:57:39 [bblfish]
- btw, if you can, let me know what the code for that is. I think I'll need it soon
- 18:57:47 [bblfish]
- I'll add it to the pg
- 19:17:00 [deiu]
- bblfish: http://fixee.org/paste/5j6t2no/
- 19:18:02 [bblfish]
- yes, but that's not good. You are searching through all the triples in the store
- 19:18:25 [bblfish]
- It would be easy for someone to break your code by accidentally adding those triples to their graph
- 19:19:12 [bblfish]
- rdflib is a quad store. The 4th element is the ?why ie the name of the graph
- 19:19:35 [bblfish]
- so one needs to know where the metadata graph of the metadata is located at
- 19:21:32 [bblfish]
- you know: say I fetch some data on the web and write those link:status triples to my store, because I want to say that I got some bad results on a web page. As long as you get those triples form my web page, who cares. But if you query all the graphs you will accidentally merge my triples with those too
- 19:21:57 [bblfish]
- s/those too/those produced by rdflib.js/
- 19:22:35 [deiu]
- Yes
- 19:23:36 [deiu]
- I'm not sure how to get to the initial ?why
- 19:24:07 [bblfish]
- mhh you need to write a print function that prints out the names of the graphs that you have in the store. There may be one in there allready.
- 19:24:22 [bblfish]
- ah you can also do
- 19:25:20 [bblfish]
- there must be some g.xxxx(undefined, $rdf.sym('http://www.w3.org/2007/ont/link#requestedURI'), $rdf.lit(uri), undefined);
- 19:26:08 [bblfish]
- but the tricky bit is to find out how one can find out from a graph automatically what the metadata graph is. Or perhaps it is the fetcher that keeps that data
- 19:26:36 [bblfish]
- I think it may be the fetcher because at one point I was finding I had more and more such mini graphs. and duplicates of things all over the place
- 19:26:39 [deiu]
- but it's not undefined
- 19:26:41 [deiu]
- it has an id
- 19:27:02 [bblfish]
- well what is needed is a N3 write out of the whole store
- 19:27:18 [bblfish]
- so that you would get for each graph a gn = { .... }
- 19:27:21 [deiu]
- the id doesn't show up in the serialization
- 19:27:40 [bblfish]
- yes, the serialiser serialises to Turtle, which is pretty misleading
- 19:27:59 [bblfish]
- given that this is a quad store
- 19:28:28 [deiu]
- I think it would be much easier to just tap into the headers when doing the GET
- 19:28:53 [bblfish]
- Wlell not really, because you want the store to for example later do conditional GETs
- 19:29:00 [deiu]
- instead of returning the error and the body, it would be useful to return the raw headers too
- 19:29:27 [bblfish]
- it's only difficult now because there is no simple method to get the metadata for a graph.
- 19:29:30 [deiu]
- so? you've still got the headers
- 19:29:43 [bblfish]
- what if you fetch the graph 20minutes later?
- 19:29:52 [deiu]
- so?
- 19:30:08 [deiu]
- I just want to check the response headers
- 19:30:09 [bblfish]
- because your user has edited something.
- 19:30:11 [deiu]
- I don't care about the graph
- 19:30:42 [bblfish]
- and he has edited something so he wants to do a PUT - but only on condition nothing has changed, to avoid overwriting something
- 19:30:49 [jmvanel]
- jmvanel has quit (Ping timeout: 240 seconds)
- 19:30:54 [bblfish]
- so all that metadata is important
- 19:31:00 [bblfish]
- to be easily available
- 19:31:00 [deiu]
- Henry
- 19:31:12 [bblfish]
- yes?
- 19:31:25 [deiu]
- I want to access the response headers when doing a nowOrWhenFetched()
- 19:31:46 [bblfish]
- I am telling you they are should be in the store. It's just data after all
- 19:32:14 [bblfish]
- you should turn the http headers into rdf like any other data
- 19:32:48 [bblfish]
- for example what if there are redirections and things like that going on.
- 19:33:06 [bblfish]
- ( not sure if rdflib captures that, btw. but it may )
- 19:33:49 [bblfish]
- so what's needed is for a PointedGraph to have a meta method that gives you exactly those headers that were sent for that PG
- 19:34:14 [bblfish]
- but you can do something ad hoc too of course :-)
- 19:34:52 [deiu]
- Sure
- 19:41:00 [bblfish]
- I see this in the recend code
- 19:41:08 [bblfish]
- // Look up response header
- 19:41:08 [bblfish]
- //
- 19:41:08 [bblfish]
- // Returns: a list of header values found in a stored HTTP response
- 19:41:10 [bblfish]
- // or [] if response was found but no header found
- 19:41:12 [bblfish]
- // or undefined if no response is available.
- 19:41:14 [bblfish]
- //
- 19:41:16 [bblfish]
- this.getHeader = function(doc, header) {
- 19:41:18 [bblfish]
- var kb = this.store;
- 19:41:20 [bblfish]
- var requests = kb.each(undefined, tabulator.ns.link("requestedURI"), doc.uri);
- 19:41:22 [bblfish]
- for (var r=0; r<requests.length; r++) {
- 19:41:24 [bblfish]
- request = requests[r];
- 19:41:26 [bblfish]
- if (request !== undefined) {
- 19:41:28 [bblfish]
- var response = kb.any(request, tabulator.ns.link("response"));
- 19:41:30 [bblfish]
- if (request !== undefined) {
- 19:41:32 [bblfish]
- var results = kb.each(response, tabulator.ns.httph(header.toLowerCase()));
- 19:41:34 [bblfish]
- if (results.length) {
- 19:41:36 [bblfish]
- return results.map(function(v){return v.value});
- 19:41:38 [bblfish]
- }
- 19:41:40 [bblfish]
- return [];
- 19:41:42 [bblfish]
- }
- 19:41:44 [bblfish]
- }
- 19:41:46 [bblfish]
- }
- 19:41:48 [bblfish]
- return undefined;
- 19:41:50 [bblfish]
- };
- 19:42:39 [bblfish]
- but as I argued above that is broken, becuse it should not search through the whole database
- 19:43:05 [bblfish]
- my guess is: a lot of students writing this code, who don't always understand NamedGraphs
- 19:56:18 [gedonist]
- gedonist (~gedonist@62.122.73.122) has joined #dig
- 19:59:42 [bblfish]
- ah I was looking at an old version of rdflib
- 20:01:10 [jmvanel]
- jmvanel (~jmvanel@123.0.88.79.rev.sfr.net) has joined #dig
- 20:07:48 [cheater]
- cheater has quit (Ping timeout: 265 seconds)
- 20:09:19 [cheater]
- cheater (~cheater@37.83.245.120) has joined #dig
- 20:12:48 [bblfish]
- ( thought I was looking at a new version but was comparing with an old version there!)
- 20:13:02 [bblfish]
- SO not sure if that getHEader method is still in there
- 20:23:30 [jmvanel]
- jmvanel has quit (Quit: Quitte)
- 20:24:58 [Ralph]
- Ralph has quit ()
- 20:26:53 [gedonist]
- gedonist has quit (Remote host closed the connection)
- 20:30:59 [jmvanel]
- jmvanel (~jmvanel@123.0.88.79.rev.sfr.net) has joined #dig
- 20:37:49 [amy]
- amy has left #dig
- 21:19:22 [cheater]
- cheater has quit (Read error: No route to host)
- 21:59:40 [cheater]
- cheater (~cheater@p57AEB6CE.dip0.t-ipconnect.de) has joined #dig
- 22:44:16 [deiu]
- deiu has quit (Quit: Leaving)