IRC log of dig on 2010-09-01

Timestamps are in UTC.

00:03:56 [oshani]
oshani has quit (Quit: Mama nidi!)
00:05:09 [oshani]
oshani (~oshani@31-33-38.wireless.csail.mit.edu) has joined #dig
00:11:04 [nunnun_away]
nunnun_away is now known as nunnun
00:16:40 [nunnun]
nunnun is now known as nunnun_away
00:17:35 [lkagal]
lkagal (~lkagal@pool-96-237-240-136.bstnma.fios.verizon.net) has joined #dig
00:45:39 [mcherian]
mcherian has quit (Ping timeout: 258 seconds)
00:59:10 [marisol]
marisol (~marisol@pool-151-203-248-155.bos.east.verizon.net) has joined #dig
01:09:54 [melvster]
melvster has quit (Ping timeout: 265 seconds)
01:20:45 [kennyluck_]
kennyluck_ (~kennyluck@EM114-48-84-14.pool.e-mobile.ne.jp) has joined #dig
01:23:48 [kennyluck]
kennyluck has quit (Ping timeout: 240 seconds)
01:23:48 [kennyluck_]
kennyluck_ is now known as kennyluck
02:20:31 [marisol]
marisol has quit (Quit: marisol)
02:29:16 [nunnun_away]
nunnun_away is now known as nunnun
02:29:17 [nunnun]
nunnun is now known as nunnun_away
02:29:19 [nunnun_away]
nunnun_away is now known as nunnun
03:03:36 [lkagal]
lkagal has quit (Quit: lkagal)
03:05:39 [oshani]
oshani has quit (Quit: Mama nidi!)
03:21:39 [lkagal]
lkagal (~lkagal@pool-96-237-240-136.bstnma.fios.verizon.net) has joined #dig
03:37:29 [oshani]
oshani (~oshani@c-71-233-151-72.hsd1.ma.comcast.net) has joined #dig
03:56:41 [lkagal]
lkagal has quit (Quit: lkagal)
04:32:12 [oshani]
oshani has quit (Quit: Mama nidi!)
05:48:02 [kennyluck]
kennyluck has quit (Quit: kennyluck)
06:03:24 [knappy]
knappy (~haoqi@18.111.59.106) has joined #dig
06:08:19 [knappy]
does anyone know the code to 32-083
06:13:28 [knappy]
knappy has quit (Quit: knappy)
07:02:29 [savinos]
savinos (~savino@host153-234-dynamic.18-79-r.retail.telecomitalia.it) has joined #dig
07:17:06 [kennyluck]
kennyluck (~kennyluck@2001:200:1c0:2900:225:ff:fe4d:f8c7) has joined #dig
07:17:28 [savinos]
hi all
07:41:11 [mhausenblas]
mhausenblas (~mhausenbl@wg1-nat.fwgal01.deri.ie) has joined #dig
07:53:10 [SimpsonTP]
SimpsonTP (~bart@office.netage.nl) has joined #dig
08:24:52 [SimpsonTP]
SimpsonTP has quit (Quit: Ex-Chat)
08:24:59 [savinos]
savinos has quit (Quit: savinos)
08:50:18 [kennyluck]
kennyluck has quit (Ping timeout: 240 seconds)
08:57:44 [kennyluck]
kennyluck (~kennyluck@2001:200:1c0:2900:226:8ff:fe07:40c6) has joined #dig
08:59:31 [melvster]
melvster (~melvster@p5797FC80.dip.t-dialin.net) has joined #dig
09:00:59 [kennyluck]
kennyluck has quit (Remote host closed the connection)
09:01:17 [kennyluck]
kennyluck (~kennyluck@2001:200:1c0:2900:226:8ff:fe07:40c6) has joined #dig
09:02:00 [kennyluck]
kennyluck has quit (Remote host closed the connection)
09:02:32 [kennyluck]
kennyluck (~kennyluck@2001:200:1c0:2900:226:8ff:fe07:40c6) has joined #dig
09:36:04 [kennyluck]
kennyluck has quit (Remote host closed the connection)
09:36:10 [kennyluck]
kennyluck (~kennyluck@2001:200:1c0:2900:226:8ff:fe07:40c6) has joined #dig
09:54:33 [knappy]
knappy (~haoqi@18.111.59.106) has joined #dig
09:55:03 [knappy]
knappy has left #dig
10:53:36 [oshani]
oshani (~oshani@c-71-233-151-72.hsd1.ma.comcast.net) has joined #dig
11:03:44 [lkagal]
lkagal (~lkagal@pool-96-237-240-136.bstnma.fios.verizon.net) has joined #dig
11:07:59 [oshani]
oshani has quit (Quit: Mama nidi!)
11:28:37 [Ralph]
Ralph (~swick@30-7-139.wireless.csail.mit.edu) has joined #dig
11:28:49 [Ralph]
Ralph is now known as RalphS
11:42:16 [oshani]
oshani (~oshani@c-71-233-151-72.hsd1.ma.comcast.net) has joined #dig
12:13:38 [lkagal]
lkagal has quit (Quit: lkagal)
12:44:06 [oshani]
oshani has quit (Quit: Mama nidi!)
12:45:51 [mcherian]
mcherian (~mathew@30-6-25.wireless.csail.mit.edu) has joined #dig
12:58:07 [bblfish]
bblfish (~bblfish@wlan-nat.fwgal01.deri.ie) has joined #dig
13:03:41 [oshani]
oshani (~oshani@31-33-38.wireless.csail.mit.edu) has joined #dig
13:08:25 [SimpsonTP]
SimpsonTP (~bart@office.netage.nl) has joined #dig
13:08:31 [SimpsonTP]
hi
13:10:16 [kennyluck]
kennyluck has quit (Quit: kennyluck)
13:10:42 [lkagal]
lkagal (~lkagal@30-6-179.wireless.csail.mit.edu) has joined #dig
13:15:08 [timbl]
timbl (~timbl@31-33-143.wireless.csail.mit.edu) has joined #dig
13:16:48 [mcherian]
mcherian has quit (Ping timeout: 240 seconds)
13:26:59 [SimpsonTP]
hi guys I'm still fighting with getting the fetcher from rdflib.js working in my own code
13:30:40 [marisol]
marisol (~marisol@31-33-212.wireless.csail.mit.edu) has joined #dig
13:31:42 [mhausenblas]
hm, not sure if I'm able to help, SimpsonTP but what's the problem?
13:32:25 [SimpsonTP]
I've created a sparql query which goes beyond the bounds of what I have in my kb
13:32:52 [SimpsonTP]
so I need to load the resource that is beeing pointed to
13:32:56 [mhausenblas]
right
13:33:04 [mhausenblas]
did you hg pull already?
13:33:13 [SimpsonTP]
( side note, it all works in tabulator , so data + query are correct )
13:33:20 [mhausenblas]
ok
13:33:32 [SimpsonTP]
yesterday, since before the fetcher was not there, and I 'hacked' it myself
13:33:59 [mhausenblas]
ok
13:34:05 [mhausenblas]
can you read https://lists.csail.mit.edu/mailman/private/tabulator/2010-August/005906.html
13:34:29 [mhausenblas]
if not, happy to forward to you
13:34:51 [mhausenblas]
(maybe a good idea anyway, hence timbl asked for your email address)
13:35:32 [SimpsonTP]
I indeed need a pw for that
13:36:02 [mhausenblas]
ok, then please gimme your email so that I can forward this msg
13:36:13 [SimpsonTP]
bart@netage.nl
13:36:13 [mhausenblas]
(also PM if you prefer ;)
13:36:16 [mhausenblas]
ok
13:36:38 [mhausenblas]
sent
13:37:06 [mhausenblas]
if this doesn't help, you might want to reply and I can forward to list
13:37:25 [mhausenblas]
if timbl is around you may wanna ask him to subscribe you to this list ;)
13:37:43 [SimpsonTP]
once I got it to work I'll defenitly do a blog post about ti
13:38:46 [SimpsonTP]
okay this much I understand :)
13:39:03 [mhausenblas]
very cool
13:39:08 [mhausenblas]
(re blog post)
13:39:28 [SimpsonTP]
and indeed, I got the new fetcher working, so it does call the 3rd parameter in the query
13:40:18 [SimpsonTP]
but then I'm not sure, if I should then load all the source myself, or if the fetcher object will take care of that
13:40:33 [SimpsonTP]
and the tabulator source itself is not all that helpfull either
13:40:53 [mhausenblas]
right
13:41:24 [mhausenblas]
IMO a perfect question for the list
13:42:25 [mhausenblas]
sorry for not being able to help more here. gotta dig into it myself a bit more, I guess ;)
13:43:34 [SimpsonTP]
thats why I love semweb technology ;
13:43:47 [SimpsonTP]
there is a very seldom some telling you RTFM
13:45:57 [mhausenblas]
hehe, true
13:49:20 [SimpsonTP]
I've created my own xul program which uses RDFlib.js which seems to be a nice testbed for the seperation of rdflib.js ;)
13:51:17 [mhausenblas]
ah, very good
13:51:31 [mhausenblas]
anything online available (sources)?
13:53:09 [SimpsonTP]
not yet
13:53:22 [SimpsonTP]
since I at least want it to work ;)
13:53:35 [SimpsonTP]
and its very very usecase specific
13:54:02 [mhausenblas]
ok, I see - pls keep us posted, nevertheless, should be fun to have a look at
13:55:22 [SimpsonTP]
I'll certainly do
13:55:26 [mhausenblas]
tx
14:07:44 [nunnun]
nunnun is now known as nunnun_away
14:14:14 [timbl]
secouli
14:14:43 [timbl]
sikuli
14:15:18 [timbl]
eggplant?
14:15:28 [timbl]
eggplant very complicated and fragile
14:17:29 [timbl]
- gte online mode working for non-installed users
14:17:35 [timbl]
- unit tests
14:17:45 [timbl]
- onine demo on DIG home page
14:18:34 [kennyluck]
kennyluck (~kennyluck@EM114-48-165-84.pool.e-mobile.ne.jp) has joined #dig
14:43:43 [SimpsonTP]
timbl, could you put me on the tabulator list ?
14:44:42 [oshani]
oshani has quit (Quit: Ayubowan!)
14:52:32 [oshani]
oshani (~oshani@31-33-38.wireless.csail.mit.edu) has joined #dig
14:52:35 [oshani]
oshani has quit (Client Quit)
15:02:33 [SimpsonTP]
timbl, thx
15:06:05 [timbl]
y w Ralph manages the list
15:07:48 [RalphS]
Oshani and Lalana can do as well
15:07:51 [RalphS]
(BTW)
15:08:30 [timbl]
Could you add me as admin?
15:09:22 [nunnun_away]
nunnun_away is now known as nunnun
15:14:42 [mcherian]
mcherian (~mathew@30-6-25.wireless.csail.mit.edu) has joined #dig
15:39:19 [SimpsonTP]
query.js:341 is giving me headaches, commenting it out, makes things work as they should
15:42:04 [mhausenblas]
mhausenblas has quit (Quit: mhausenblas)
15:50:57 [SimpsonTP]
I'm stil do not understand what the 3rd parameter to query the 'fetcher' should point to
15:57:26 [mcherian]
mcherian has quit (Ping timeout: 272 seconds)
15:57:33 [kennyluck]
SimpsonTP: Have you tried the "query by examples" feature?
15:57:49 [kennyluck]
s/examples/example/
15:57:59 [SimpsonTP]
what/where ?
15:58:21 [kennyluck]
The "Find All" button.
15:58:58 [kennyluck]
The fetcher is a callback for resource updating, IIRC. It is related to this particular feature.
15:59:49 [SimpsonTP]
well I'm not working inside tabulator
16:00:46 [SimpsonTP]
i'm using rdflib.js standalone
16:01:06 [SimpsonTP]
the only reference I have is how tabulator uses it internaly
16:01:10 [kennyluck]
Oh, OK. I was just talking about the origin of such construct. We don't have a "pure" SPARQL processor, IIRC.
16:01:34 [kennyluck]
It is used in a dirty way to support the "query by example" feature.
16:05:59 [SimpsonTP]
well before web.js was incorporated I used a 'ugly' hack to get this thing to work
16:06:14 [webr3]
btw, might be worth mentioning I'm being paid to recode all of rdflib in haXe at the minute (Statically typed langauge which compiles to javascript) and full unit tests etc, should be done within 10 days - api will be tabulator compatible, documented and I'll release it as haxe and js to you guys - refactoring it a bit but keeping common api methods the same
16:07:42 [SimpsonTP]
webr3, so you'll do proper docs as well ?
16:07:51 [webr3]
example: http://pastebin.com/CWBSv76g - as said though will comile it all back in to a single rdflib.js and hand back - can also do patches against current rdf lib to only fix bugs that are being caught if you want
16:08:10 [webr3]
re proper docs, just developer docs java api style without the big descriptions for now
16:10:42 [webr3]
only caveat is that I'm using some ecma v5 things like Date.toISOString() Array.forEach etc - but will do backwards compatible prototypes for them if needed
16:10:54 [webr3]
</end
16:19:46 [presbrey]
do I have to commit code for new panel types to tabulator hg?
16:20:04 [presbrey]
or can I reference panel plugin URIs locally?
16:22:10 [kennyluck]
presbrey, you mean panes?
16:22:21 [presbrey]
yes, sorry.
16:23:06 [kennyluck]
I don't think we have such feature, I maybe wrong. Timbl?
16:23:50 [timbl]
If you make a new pane and it is useful thendo commit it in te hg
16:24:13 [kennyluck]
But decentralized extensibility is desirable. :)
16:24:21 [timbl]
Oshani is working on a system to allow you to (a) check off panes the user wants in preferences and (b) load new ones at runtime from the web
16:24:24 [presbrey]
yes sure. it might be a cool feature for people that want to make panes who can't commit
16:24:55 [kennyluck]
I think we might want to look into W3C Widgets...
16:25:02 [presbrey]
cool oshani (b)!
16:25:22 [presbrey]
or perhaps RDF widgets
16:31:00 [nunnun]
nunnun is now known as nunnun_away
16:33:39 [lkagal]
lkagal has quit (Quit: lkagal)
16:33:39 [marisol]
marisol has quit (Quit: marisol)
16:40:58 [SimpsonTP]
are panels expressed in RDF ?
16:41:47 [kennyluck]
Not at the moment! Well you can't really express HTML+JavaScrpt+CSS in RDF.
16:42:09 [marisol]
marisol (~marisol@31-33-212.wireless.csail.mit.edu) has joined #dig
16:42:15 [SimpsonTP]
so they are extremly tied to browser only
16:43:07 [kennyluck]
Yes, I suppose. They are presentational.
16:45:20 [kennyluck]
I think little presentational components are very close to what people call widgets, so we can just implement the W3C Widget Packaging spec. Or course there must be some technical barriers.
16:46:17 [kennyluck]
http://www.w3.org/TR/widgets/
16:46:58 [kennyluck]
(apparently not in RDF, but well...)
16:53:25 [SimpsonTP]
imho sticking to the browser so much is not the way to go
16:53:33 [SimpsonTP]
but i'm working on that ;)
16:55:28 [timbl]
webr3, cool
16:55:41 [timbl]
HaXe interesting - how does it compare with scala?
17:00:57 [SimpsonTP]
webr3, so you will do some release management as well ?
17:04:52 [webr3]
timbl, quite a different beast - it's like ECMAScript with static typing, enums, typedefs, lamdas etc but compiles to different targets (php,js,c++,as3 etc) I've beefed up the js library on it and am using it as basically a compiler for javascript
17:05:15 [oshani]
oshani (~oshani@31-33-38.wireless.csail.mit.edu) has joined #dig
17:05:41 [webr3]
fyi: http://webr3.org/apps/play/js-haxe/multidoc/compare/ if you flick through the 4 steps you'll see what you can do better than i can describe
17:06:56 [webr3]
SimpsonTP - not thought about release management etc yet - task 1 is to get it fully functioning, unit tested and working on client + server - then from there will see after discussing with everybody here - could keep dev'ing it in haxe, or just take the compiled js output and start using that instead
17:07:32 [kennyluck]
webr3: How is HaXe compared to JavaScript 2?
17:09:32 [SimpsonTP]
okay
17:09:35 [webr3]
kennyluck, it's like javascript 2 but right now :) v nice to work with
17:13:11 [webr3]
tbh it was annoying me a bit, so I forked it and made the libs javascript specific, have added in all the web related w3c idl (so you get static typing and code completion) and all of ecmascript v3 and v5 - it's now a real pleasure to code in
17:29:11 [mcherian]
mcherian (~mathew@30-6-25.wireless.csail.mit.edu) has joined #dig
17:30:04 [oshani]
oshani has quit (Quit: Mama nidi!)
17:32:31 [oshani]
oshani (~oshani@31-33-38.wireless.csail.mit.edu) has joined #dig
17:33:35 [ktk]
ktk (~ktk@r2-d2.netlabs.org) has joined #dig
17:40:51 [SimpsonTP]
okay it took a while but I figured it out now :P
17:41:35 [SimpsonTP]
I can use rdflib.js in a standalone XUL app to do sparql queries who go out on the web to fetch more data !
17:45:52 [oshani]
oshani has quit (Quit: Mama nidi!)
17:50:48 [oshani]
oshani (~oshani@31-33-38.wireless.csail.mit.edu) has joined #dig
17:52:27 [SimpsonTP]
how to submit patches ??
18:08:05 [nunnun_away]
nunnun_away is now known as nunnun
18:10:45 [webr3]
hg patch and send to oshani or the mailing list afaik
18:10:59 [SimpsonTP]
ah I'm not yet on the list I think
18:11:04 [SimpsonTP]
it was requested though
18:11:42 [oshani]
SimpsonTP, we can add you to the list
18:12:04 [SimpsonTP]
there was already a request out
18:12:24 [oshani]
okay
18:12:50 [SimpsonTP]
whats the address of the list ?
18:12:58 [SimpsonTP]
I can see if it was processed already
18:13:13 [oshani]
tabulator@csail.mit.edu
18:15:52 [SimpsonTP]
k
18:15:58 [SimpsonTP]
let me see if it bounces ;)
18:17:04 [SimpsonTP]
can you see something on the list ?
18:19:06 [oshani]
SimpsonTP, I don't see anything right now...
18:19:54 [SimpsonTP]
nothing bounces either...
18:20:12 [oshani]
perhaps there's a delay
18:20:34 [oshani]
I am actually not an admin on the list, so I cannot add you. RalphS or timbl should be able to help you with this. BTW, who did you make the request to?
18:21:16 [oshani]
we used to get a lot of spam, so in a way it is good that we don't have a public sign up
18:23:57 [SimpsonTP]
oshani, could I mail you the patch directly ?
18:24:16 [oshani]
yeah sure..
18:24:25 [oshani]
my email is oshani@mit.edu
18:24:35 [oshani]
cc timbl@w3.org too
18:25:13 [oshani]
SimpsonTP, I think we got your email
18:25:38 [SimpsonTP]
ah :)
18:25:39 [oshani]
you are Bart_van_Leeuwen@netage.nl right?
18:25:46 [SimpsonTP]
thats me
18:25:57 [oshani]
so, you can send the patch to the list
18:26:02 [SimpsonTP]
its in that mail
18:26:12 [oshani]
ah yeah
18:26:13 [oshani]
cool
18:26:18 [oshani]
I'll look at it
18:27:43 [oshani]
looks good
18:27:46 [oshani]
thanks for the fix
18:27:50 [oshani]
I will apply it
18:28:42 [SimpsonTP]
its very simple, but this way I can use the version from hg, instead of patching one to get it working ;)
18:29:09 [SimpsonTP]
there is one very odd behavious in query, which tim already added to the bugtracker
18:29:56 [SimpsonTP]
the pattern.sort results in something unexpected which I couldn't figure out yet
18:40:42 [timbl]
webr3, re line 341 in query.js pattern.sort(easiestQuery);
18:41:11 [timbl]
It won't work without that
18:41:29 [timbl]
of all the statemnets to look for, some will be easy , some hard, and some impossible
18:41:47 [timbl]
Each time around, the engine picks the easiest one
18:49:56 [timbl]
especialy a statement anchored by a URI for aymbo
18:52:09 [webr3]
think that could have been for SimpsonTP, wasn't me that asked I'm afriad
18:52:17 [webr3]
only q I had is on the list :)
18:52:38 [SimpsonTP]
it was me
18:53:17 [SimpsonTP]
I'm trying to debug this now
18:55:13 [timbl]
ok, yes, it was
18:56:42 [SimpsonTP]
it completely beats me why this causes problems
18:59:14 [SimpsonTP]
okay I start to see what it does, but stil not why...
19:02:05 [timbl]
Suppose you are looking to solve
19:02:13 [timbl]
<tim> knows ?x
19:02:33 [timbl]
?x knows ?y
19:02:37 [timbl]
?y name ?z
19:02:40 [timbl]
-----------------
19:03:15 [timbl]
the engines tries to solve one at a time, iteratineg for ecah resiulft for that line over the other.
19:04:10 [timbl]
If it starts by finding all y and z such that y name z then it will get lots of junk and onlt a th end trim it down to naes of tim's frends, and in fact it won't find those as it won't look up my fiaf file
19:04:25 [timbl]
instead it sees the first line is easiest
19:04:32 [timbl]
it only has one variable
19:04:49 [timbl]
and the tim knows x index has only 123 items in it
19:05:02 [timbl]
so it iterates over each x
19:05:18 [timbl]
then for a given x it looks at:
19:05:36 [timbl]
whatever knows ?y
19:05:41 [timbl]
?y name ?z
19:05:50 [timbl]
and agin, it make sense to do the first line first
19:07:12 [SimpsonTP]
ack
19:08:22 [SimpsonTP]
okay I see where my problem is now
19:08:49 [SimpsonTP]
the query is not correct, since both terms have 2 variables
19:09:06 [SimpsonTP]
?msg <fd:hasunit> ?unit
19:09:20 [SimpsonTP]
?unit <rdfs:label> ?label
19:09:43 [timbl]
I think there may be currently a big such that when it has to wait to load x then it only binds one value of x evn though there ay be >1 value of x which matches in the graph just loaded
19:09:52 [SimpsonTP]
what happens if I have just 2 units, it works, because both the label query ,and the unit will return in this graph
19:10:01 [SimpsonTP]
so the sort order is not modified
19:10:47 [timbl]
but you can imagine a world in which there are 3 messages and 10,000 units and labels
19:10:49 [SimpsonTP]
but when there are more the 2 units, it will do the label query first, since the graph has 2 labels define...
19:11:00 [timbl]
in that case it is worth doing the ?msg one first
19:11:21 [SimpsonTP]
sure, but I need to specify the ?msg
19:11:28 [timbl]
It h=just has to compare the predicate indxes for hasunit (3 long) ad rdfs:label (10,000 or more)
19:11:38 [SimpsonTP]
then all problems are solved, I just didn't get why it did this
19:11:41 [timbl]
No, youdon't have to specify the ?msg
19:11:56 [timbl]
It should be able to solve that one
19:12:11 [SimpsonTP]
well currently it doesnt :)
19:12:12 [nunnun]
nunnun has quit (Read error: Operation timed out)
19:12:25 [timbl]
There may be a bug
19:12:32 [timbl]
testsuite++
19:12:34 [SimpsonTP]
well you created a issue already
19:12:47 [SimpsonTP]
( of which I forgot the uri )
19:14:21 [SimpsonTP]
but if I specify the ?msg in the query , which I know at the time because I want to show info about A specific incident instead of all
19:14:29 [SimpsonTP]
then my problem is solved for now
19:16:27 [timbl]
ok
19:17:40 [SimpsonTP]
next try will be to see if rdflib.js will work on WebOS ;)
19:20:20 [betehess]
betehess (~betehess@betehess.w3.org) has joined #dig
19:24:43 [SimpsonTP]
ah no first thing will be a blog post on how got this stuff to work without documentation ;)
19:26:44 [webr3]
why not just write some docs in the code instead and submit a patch? anythings better than nothing
19:29:55 [SimpsonTP]
uhm, no patch needed
19:41:15 [SimpsonTP]
webr3, whats your mail ?
19:42:03 [webr3]
nathan@webr3.org :)
19:43:37 [SimpsonTP]
webr3, ygm
20:19:42 [RalphS]
RalphS has quit (Quit: leaving ...)
20:20:56 [kennyluck]
kennyluck has quit (Ping timeout: 255 seconds)
20:26:26 [kennyluck]
kennyluck (~kennyluck@EM114-48-32-220.pool.e-mobile.ne.jp) has joined #dig
20:34:20 [SimpsonTP]
webr3, ygm again
20:56:26 [lkagal]
lkagal (~lkagal@30-6-179.wireless.csail.mit.edu) has joined #dig
20:56:31 [lkagal]
timbl, http://www.nsf.gov/pubs/2010/nsf10575/nsf10575.htm
20:56:35 [timbl]
tx
20:59:22 [lkagal]
lkagal has quit (Quit: lkagal)
20:59:50 [marisol]
marisol has quit (Quit: marisol)
21:05:18 [lkagal]
lkagal (~lkagal@30-6-179.wireless.csail.mit.edu) has joined #dig
21:07:19 [timbl]
timbl has quit (Quit: timbl)
21:12:03 [timbl]
timbl (~timbl@31-33-143.wireless.csail.mit.edu) has joined #dig
21:53:32 [ktk]
ktk is now known as ktkNA
21:54:29 [SimpsonTP]
SimpsonTP has quit (Ping timeout: 272 seconds)
21:58:58 [nunnun]
nunnun (~nunnun@2001:268:355:20::6667:1) has joined #dig
22:02:55 [Pipian]
Pipian has quit (Remote host closed the connection)
22:07:50 [lkagal]
lkagal has quit (Quit: lkagal)
22:14:08 [kennyluck]
kennyluck has quit (Quit: kennyluck)
22:26:48 [presbrey]
wow the apache (parent) directory and location walking code is >1000 lines
22:27:47 [presbrey]
do we care about merging parent RDF ACLs or simply using the closest ACL to the request URI?
22:27:59 [webr3]
timbl, I'm rewriting IndexedFormula at the minute and wondering if the semantics of link:uri are to be considered the same as owl:sameAs for smushing together? (off now but will pick up answer in the am)
22:29:49 [webr3]
presbrey, would have thought it was the closest to the uri - however do we need a 'can overwrite' type property on ACLs so hosts can prevent unauthorized/overridden access further down the directory tree? (if that's what you mean)
22:29:52 [presbrey]
but not much else
22:30:36 [presbrey]
its nice to see how they do it though... love oss
22:31:01 [presbrey]
webr3, I'm comparing to .htaccess merge rules
22:31:43 [presbrey]
http://tabulator.org/wiki/private/ merges /wiki/private/.ht + /wiki/.ht + /.ht
22:32:25 [presbrey]
thinking about merging /wiki/private/.n3 + /wiki/.n3 + /.n3 vs. only /wiki/private/.n3
22:42:45 [melvster]
melvster has quit (Remote host closed the connection)
22:43:03 [melvster]
melvster (~melvster@p5797FC80.dip.t-dialin.net) has joined #dig
23:26:11 [presbrey]
webr3, re. can overwrite property
23:27:04 [presbrey]
that is an important protection
23:29:19 [presbrey]
overwriting inheritance in general
23:29:42 [presbrey]
is this the 'allowoverride all,none' of .htaccess?
23:29:57 [oshani]
oshani has quit (Quit: Mama nidi!)
23:31:05 [presbrey]
I've also been thinking about a preloaded RDF store/cache
23:32:42 [presbrey]
maybe storing/crawling metadata of some configurable distance
23:33:04 [presbrey]
graph{} constraints in the ACL SPARQL
23:35:08 [presbrey]
getting graph context working in the store
23:36:06 [presbrey]
and caching
23:37:01 [presbrey]
how it might work with webfinger and proxy authentication
23:57:22 [timbl]
do we care about merging parent RDF ACLs or simply using the closest ACL to the request URI? it should always be the parent, as when any directory is created the default shoul dbe propagated immediatey and so be available.
23:57:45 [timbl]
¿¿¿rewriting IndexedFormula???
23:58:17 [timbl]
No, link:uri is just used in the UI for connecting a thing with a string
23:58:24 [timbl]
not like owl:sameAs
23:58:47 [timbl]
lin:uri is not for export, only generated transiently in the UI for the internals pane