IRC log of dig on 2011-01-28

Timestamps are in UTC.

13:40:45 [DIGlogger]
DIGlogger (~dig-logge@groups.csail.mit.edu) has joined #dig
13:40:45 [jordan.freenode.net]
topic is: Decentralized Information Group @ MIT http://dig.csail.mit.edu/
13:40:45 [jordan.freenode.net]
Users on #dig: DIGlogger danbri RalphS marisol melvster tlr IvanHerman mhausenblas bblfish1 betehess kennyluck timbl webr3 presbrey jambo sandro ericP manu1 gbot30 der-rho-ist Ipaparrizos nunnun manu-db
14:01:03 [tlr]
tlr has quit (Remote host closed the connection)
14:01:36 [tlr]
tlr (~tlr@2001:470:1f13:4d4:226:8ff:fee6:f0e8) has joined #dig
14:54:39 [mhausenblas]
mhausenblas has quit (Ping timeout: 240 seconds)
14:56:30 [bblfish1]
bblfish1 is now known as bblfish
14:59:25 [amy]
amy (~amy@30-5-15.wireless.csail.mit.edu) has joined #dig
15:06:54 [bblfish]
hi
15:20:48 [Pipian_]
Pipian_ (~pipian@w3cdhcp27.w3.org) has joined #dig
15:28:41 [marisol]
marisol has quit (Quit: marisol)
16:07:10 [lkagal]
lkagal (~lkagal@30-6-179.wireless.csail.mit.edu) has joined #dig
16:30:06 [IvanHerman]
IvanHerman has quit (Quit: bye guys)
17:21:35 [mhausenblas]
mhausenblas (~mhausenbl@wlan-nat.fwgal01.deri.ie) has joined #dig
17:31:22 [mhausenblas]
mhausenblas has quit (Quit: brb)
18:03:31 [presbrey]
I'm rebooting dig xvm momentarily to pick up an additional IP for SSL
19:27:29 [presbrey]
ok so we got an additional IP for the tabulator site
19:27:48 [presbrey]
tabulator.org now points to tabulator.xvm.mit.edu (18.181.1.88)
19:28:19 [presbrey]
which is co-hosted with dig.xvm.mit.edu (18.181.1.220)
19:29:13 [presbrey]
but no longer a name-based virtualhost
19:29:31 [presbrey]
so now earlier browsers without SNI support will still get a valid tabulator.org SSL certificate
19:29:51 [timbl]
If you have to have a virtual address the one which is all 8s isn't all that bad ;-)
19:30:22 [presbrey]
hehe true all 1s and 8s
19:34:34 [timbl]
Testing of the tabulator is now in order
19:34:55 [timbl]
The form stuff basically works
19:35:00 [presbrey]
DNS must still propagate -- for the new IP to take effect and SSL error to go away
19:35:11 [presbrey]
/ns/ui#FormForm ?
19:35:12 [timbl]
ok
19:35:47 [presbrey]
the cascade is quite impressive
19:36:31 [presbrey]
we should put together a set of turtle/n3 for consistent testing of tabulator between official releases
19:36:39 [timbl]
That is using the form form to look at itself
19:36:54 [presbrey]
at least 1 test graph per pane
19:39:04 [timbl]
yes
19:40:24 [timbl]
There is also http://dig.csail.mit.edu/hg/tabulator/raw-file/tip/content/test/index.html
19:40:42 [timbl]
aka chrome:...
19:41:28 [presbrey]
cool I had n ot seen that
19:42:04 [timbl]
Michael Hausenblas nd folks at DERI make it
19:42:08 [timbl]
I added a few
19:46:20 [presbrey]
only 1, 2, and 5 run green on my latest
19:46:30 [presbrey]
0, 3, and 4 are red
19:49:15 [timbl]
Yes ... the ones that fail are faily obscrure IIRC
19:49:53 [timbl]
like inference from a inverse functional property being added to existing data .. reasonable but doesn't get in the way
19:50:35 [timbl]
And the URI tests are auguable
19:50:58 [timbl]
What i sthe relative URI for http://example.com/.meta.n3">http://example.com/.meta.n3 relative to http://example.com/.meta.n3 ? I would sy ""
19:51:25 [timbl]
but they sy "meta.n3". Both work, but the tabulator one is bettrer IMHO
19:52:00 [presbrey]
yes, "" is relative for x at x
19:52:01 [timbl]
The same pairs of testdata are used for going both ways, but it isn't reversible.
19:52:15 [timbl]
so the test needs fixing.
19:52:51 [timbl]
But there are many tests missing, for sparql, for inference in general
19:53:04 [timbl]
I have some little RDFS routines now
19:53:12 [timbl]
which the forms find useful.
19:54:00 [bblfish1]
bblfish1 (~bblfish@ALagny-551-1-160-99.w90-35.abo.wanadoo.fr) has joined #dig
19:55:03 [timbl]
The fom now generates a default place to store tself which is like tabulator.org/annotation/ then the URI of the thing annotated
19:57:41 [bblfish]
bblfish has quit (Ping timeout: 264 seconds)
20:08:31 [kennyluck]
kennyluck has quit (Quit: kennyluck)
20:10:38 [timbl]
Like http://tabulator.org/wiki/annotation/www.w3.org/2002/12/cal/ical/ for a form about ical
20:15:29 [Pipian_]
webr3, was wondering what discussions there have been about GraphLiteral in the RDF API? I'm at the point where I'm trying to make a decision about when graphs should be transient and when they should be durable in this indexedDB implementation, and having an idea about how GraphLiterals work would probably help given that I'm probably going to need some identifier for a graph in order to pull it out again after it's stored.
20:17:14 [Pipian_]
(otherwise, I've got a working implementation of the rest of the basic and environment APIs (but not any of the data APIs) from the 09 Dec draft.
21:02:43 [bblfish1]
bblfish1 has quit (Quit: Leaving.)
21:04:52 [bblfish]
bblfish (~bblfish@ALagny-751-1-1-8.w86-218.abo.wanadoo.fr) has joined #dig
21:10:55 [manu1]
Pipian_, have you seen the latest RDF API spec? http://www.w3.org/2010/02/rdfa/sources/rdf-api/
21:11:00 [manu1]
discusses GraphLiterals a bit
21:12:13 [manu1]
and Nathan's blog post on GraphLiterals is a good intro: http://webr3.org/blog/semantic-web/rdf-named-graphs-vs-graph-literals/
21:12:46 [manu1]
other than that, the group has been focusing on RDFa Core for the last 2 months (I'm an RDFa Working Group Chair, btw).
21:13:27 [manu1]
so not much discussion inside the group - but our company has implemented Graph Literals in our data store because we needed to freeze certain graphs.
21:13:45 [manu1]
(we freeze all graphs that are time sensitive - which is most of the data in our systems)
21:14:06 [manu1]
Things like financial transfers: http://payswarm.com/vocabs/commerce#transfer
21:20:05 [RalphS]
RalphS has quit (Quit: outah here ...)
21:22:01 [webr3]
Pipian, wonderful how did you find implementing it thus far?
21:23:21 [webr3]
manu1, cheers for pointing out that post - and, pipian has been implementing the draft api, sounds like he's almost done :)
21:24:15 [manu1]
good to know - source released for it yet? Would be good to have both your JS3 impl and Pipian's - two interop implementations before W3C Last Call would be great :)
21:25:52 [webr3]
def, even better if we can share components too! for instance Pipian, I've got many of the data api's implemented, serializers and parsers - if you're in JS then we should be able to just "drop them in"
21:29:22 [webr3]
ericP, got some feedback on the text/n3 registration template you sent through, will reply tonight, need to give jar some feedback on something first
21:32:39 [timbl]
webr3, making the API convenient is importnat.
21:32:47 [timbl]
So grpah.add(s,p,o)
21:33:14 [timbl]
is actually 10* more useful than graph.add(new $rdf.Triple(splo))
21:35:56 [bblfish]
hi timbl
21:36:08 [timbl]
Hi bblfish, ho's life?
21:36:31 [bblfish]
good, started my unemployed life working on WebID XG :-) Keeping me busy
21:37:27 [webr3]
timbl, i agree, but graph.add would need three slots for each s,p,o (data,lang,type),(data,lang,type),(data,lang,type) - so I'd been concerned about this, and thought it may be beneficial to include the standard (and often needed) add(triple) in the api, then allow implementations to add on all the convenience methods - even if add(s,p,o) was given, surely we'd still need add(t)?
21:39:16 [timbl]
No, you don't need lang, data, type
21:39:23 [timbl]
as 3 sep params
21:39:43 [timbl]
you pass node objects or raw data types like bare strings or numbers
21:40:33 [timbl]
You have a different defintion of graph.the
21:41:08 [webr3]
other definition?
21:41:22 [manu1]
so, graph.add("http://example.org/about#me", "http://xmlns.com/foaf/0.1/age", 5); would generate this triple -
21:41:25 [timbl]
I've written a lot of code using the tabulator API and it has got smoother to use wit time.
21:41:46 [manu1]
<http://example.org/about#me> <http://xmlns.com/foaf/0.1/age> "5"^^xsd:integer . ?
21:42:36 [timbl]
kb.add(about('me'), foaf('age'), 5);
21:42:43 [manu1]
(along with being able to pass in S, P, O as nodes)?
21:42:54 [timbl]
I just di dpass S P adn O as nodes
21:43:20 [manu1]
right, but about('me') => JavaScript String, or about('me') == RDFNode?
21:43:28 [timbl]
You can make changes to this API so long as it makes it slicker.
21:43:45 [manu1]
just trying to understand exactly what you're asking for.
21:43:46 [timbl]
about('me') -> RDFNode
21:44:08 [manu1]
ok, so there would never be the case where foaf('age') would be a JavaScript string?
21:44:19 [timbl]
never
21:44:28 [manu1]
ok, good - I thought you were partially asking for that.
21:44:38 [timbl]
foaf = $rdf.ns('http://....");
21:44:47 [webr3]
timbl, you can, but is that in the realm of the library or the API focussed on interop between implementations? surely if one makes it like a library API, then all libraries will be identical? (rather than interopable modules adding on thier own benefits and streamlined jquery/tabulator like apis)
21:45:10 [timbl]
?
21:45:28 [manu1]
the other assumption is that 5 will be automatically identified as an xsd:integer?
21:45:35 [timbl]
I want to be abel to run the tabulator code on soemone else'd library
21:45:58 [timbl]
I don't mind a common code like jquery being open source shared utilities.
21:46:03 [manu1]
(meaning, we have to put that in the spec - all integers are automatically recognized as xsd:integer)
21:46:07 [webr3]
timbl I'd been focussing this to allow tabulator and the other libs to work together and swap components, rather than defining a "perfect" api for end users, similarly so advanced users can have create code running of the api that works with any impelemntation fo the api
21:46:16 [timbl]
manu1: (meaning, we have to put that in the spec - all integers are automatically recognized as xsd:integer) -- YES
21:46:27 [timbl]
That is what makes a usable spec from the devlopers POV
21:46:38 [timbl]
You can also overload graph.add()
21:48:22 [timbl]
you can make it take 3 (or 4) params and there is only oine defined and it is of type triple, the add the triple.
21:48:22 [webr3]
yes and yes, that's what I'm hoping people will do - I already do in my own libs for instance - they're build on, and wrap, the api
21:48:22 [timbl]
They need to be standard too
21:48:22 [timbl]
Well certianly graph.add() ahs to be
21:48:47 [webr3]
yeah, i do agree, and would prefer that, need to look in tot he 'ol idl and see how one can define the overloading
21:48:51 [timbl]
By the way th eforAech(filter) is not a call I ca think I would ever make to the API.
21:48:59 [timbl]
forEach()
21:49:09 [webr3]
:) it's one i use the most!
21:49:20 [timbl]
"manu1: (meaning, we have to put that in the spec - all integers are automatically recognized as xsd:integer)"
21:49:29 [timbl]
sorry wrong paste
21:49:37 [timbl]
"host language native sequence, for example an Array in ECMAScript-262."
21:50:05 [manu1]
forEach is very important for us...
21:50:07 [webr3]
timbl, js now has [].forEach and [].filter
21:50:20 [manu1]
mirrors jQuery, so our developers are used to thinking about data like that.
21:50:25 [manu1]
plus, what webr3 said :)
21:51:15 [timbl]
(sorry, I meant not forEach, every I meant)
21:51:28 [webr3]
graph.forEach( function(t) ) { print t } );
21:51:46 [manu1]
ah, yes
21:51:55 [manu1]
every() probably will never be used.
21:52:13 [timbl]
forEach is like list.map()
21:52:18 [timbl]
but no returned list
21:52:22 [timbl]
You can use map()
21:52:30 [timbl]
if you have it and ignore the return
21:52:47 [manu1]
but in order to align with ECMAScript-262, it would be good to specify how it works (in case people want to use ECMA arrays to implement)
21:52:48 [timbl]
"manu1: every() probably will never be used" we agree
21:52:58 [webr3]
see: https://developer.mozilla.org/en/JavaScript/Reference/Global_Objects/Array#Methods
21:53:19 [manu1]
that's not the best argument (ECMA alignment), though...
21:53:19 [webr3]
("Iteration methods")
21:54:05 [webr3]
and in all honesty, having used the api, the methods do all get used a lot, granted .some far mroe often then .every, but still used
21:54:38 [manu1]
when do you use .every, webr3?
21:55:00 [timbl]
But you don't have the and any and each which I use all the time!
21:55:22 [timbl]
internally in what?
21:55:48 [manu1]
(internally at our company)
21:55:52 [webr3]
timbl, will look at any and each - thought I'd covered those
21:55:56 [manu1]
for our graph store implementation
21:55:59 [manu1]
and API
21:56:22 [timbl]
You have a reference one in javascript?
21:56:29 [timbl]
Have you looket at the tabulato rone?
21:56:40 [timbl]
Have you looked at the tabulator one?
21:57:11 [manu1]
We have our own implementation in C++ - https://github.com/digitalbazaar/monarch/wiki
21:57:23 [webr3]
manu1, of this api?
21:57:41 [manu1]
unfortunately, we haven't pushed any of the latest stuff because we're still working out how to best accomplish some of the stuff being discussed in the RDF API.
21:57:44 [timbl]
It is really important that this API use all the clever Javascript things it can t be a delight to JS developers.
21:58:24 [timbl]
The goal as I understand it is the AJAX market. This is not a multi-language IDL definition.
21:58:31 [manu1]
webr3, nope, not of this API - just general graph interfaces. We deal with all of our data in JSON-like structures.
21:58:50 [manu1]
right, and that's where we want to focus - JavaScript, in browser.
21:59:17 [manu1]
I was just asking about every() - for any graph store. Is there any graph store that exposes that type of function?
22:00:08 [manu1]
timbl - yes, this is not a multi-language IDL definition - but we're also trying to keep languages like C++ in mind.
22:00:30 [webr3]
manu1, it's just forAll and forSome, two v basic existential/universal quanitifiers (likewise the)
22:00:32 [ericP]
webr3, i'm curious about the feedback on the reg -- was it about security considerations?
22:01:05 [manu1]
timbl - if we can get an API that can be implemented in JavaScript and languages like Python, Ruby and C++ - then, that would be better than just JavaScript. Granted, we don't want to cut fantastic JavaScript features for the benefit of C++.
22:01:21 [webr3]
ericP, minor on security, magic numbers (i don't think @base and @prefix are magic numbers) and really think we need to word the utf8 stuff correctly else they'll block it again from going text tree
22:01:24 [ericP]
(btw, which template, the one to ieft-types (with text/rdf+n3) or to us about figuring out what to ask for?
22:01:32 [manu1]
So, primary focus is on JavaScript - if we can bring the other languages along for the ride - all the better.
22:01:35 [webr3]
ericP, the one to us
22:01:39 [timbl]
webr3, G.the(S,P) returns all O such that SPO is in G. graph.the(S,,O) returns all P, G.the(,PO) returns all S.
22:02:19 [ericP]
i think we're fine re: the utf-8 so long as we include a charset parameter
22:02:22 [webr3]
timbl, .any and .each can be implemented w/ the api, as in filter can be used (assured they could be implemented) but aren't defined - and ahh .the does conflict w/ tabulator method - will need to address
22:02:38 [ericP]
webr3, i think you need someone else to pester you right now
22:02:50 [webr3]
ericP lol
22:02:50 [timbl]
manu1, it is a question of whether you end up sacrificing things the ability to overload functions, or make them do the right thing with eithe x or an array of x, and so on, which cuts down the amount code people have to wite
22:03:10 [webr3]
timbl, manu - I'm v wary about even attempting to defining a "perfect" api for end use by developers..
22:03:25 [manu1]
timbl, webr3 - all good points
22:04:02 [timbl]
If you don't define them then people won't code with them and won't rely on them, or they will use differemt layers to make the thing usable.
22:04:03 [manu1]
timbl - As a general rule, we don't want to sacrifice parameter overloading - yes, we want to be able to pass in either x or an array of X.
22:04:14 [timbl]
Good
22:04:25 [presbrey]
when auto-promoting native types in G.add, how do you discriminate between a URL and Literal object?
22:04:54 [timbl]
For example, the sparql.update(del,ins, callback) which presbrey wrote del and ins can be either statements or arrays of them or graphs
22:05:10 [manu1]
presbey - one approach: you don't - a string is a string - PlainLiteral
22:05:12 [presbrey]
also, G.add should accept relative URLs relative to G.baseURI
22:05:28 [manu1]
presbey, if you want a URL, you pass in an RDFNode.
22:05:39 [timbl]
presbrey, you can't pas a URL raw as a node.
22:05:40 [manu1]
(that's just one approach, not claiming it will be the final approach)
22:05:41 [webr3]
timbl, manu1, see the top 10 lines of: http://lists.w3.org/Archives/Public/public-rdfa-wg/2011Jan/0091.html
22:05:48 [timbl]
it would be interpreted as a sring
22:06:15 [presbrey]
are RDF subjects and predicates still /always/ URIs?
22:06:32 [webr3]
presbrey, not in the api, just node node node
22:06:41 [manu1]
As it's defined right now - they are RDFNodes
22:07:07 [presbrey]
interesting
22:07:21 [manu1]
yes, to say the least :P
22:07:46 [timbl]
What does GT stand for in you email?
22:08:03 [webr3]
"generalized triples" people have coined the term, node,node,node
22:08:23 [timbl]
Ah.
22:08:30 [timbl]
Yes, what I call triple
22:08:37 [webr3]
snap
22:08:38 [timbl]
well actually statement
22:08:44 [webr3]
although RDF GT has a certain ring to it lol
22:08:49 [timbl]
but happy to move to triple
22:08:52 [webr3]
it's better and faster, ha!
22:09:15 [manu1]
yes, except that the RDF community has come to understand "triple" as bnode/URI URI bnode/URI/Literal
22:09:23 [timbl]
but there is an optional 4th triple.why element too which is n RDFNode correspnding to the document which was the source of the triple
22:09:43 [manu1]
This is where Graph Literals come in.
22:10:13 [timbl]
?
22:10:14 [manu1]
We don't believe that the 4th element is necessary (a quad instead of a triple)
22:10:34 [manu1]
perhaps I misunderstood your "4th" statement.
22:10:51 [manu1]
you're talking about provenance, right?
22:11:04 [timbl]
: but there is an optional 4th part to the triple, triple.why element too which is n RDFNode correspnding to the document which was the source of the triple
22:11:11 [manu1]
so your 4th item is: subject, predicate, object, ORIGIN ?
22:11:14 [timbl]
Yes provenance
22:11:31 [timbl]
Both cwm and tabulator found they needed it
22:11:53 [timbl]
to find out where a triple came from, so that you can for example goedit it
22:11:57 [webr3]
RDFa really needs it too
22:12:22 [manu1]
well, Linked Data needs it.
22:12:41 [webr3]
mnhh unsure..
22:12:42 [timbl]
yes, the field name for ORIGIN is actually called "why" as in an inference engine it can be a more complicated, but yes, origin
22:12:44 [timbl]
.
22:12:44 [manu1]
and timbl, we're afraid that you can't just talk about data by naming it - you have to freeze it
22:12:54 [manu1]
take financial data for instance.
22:13:04 [manu1]
or legal information.
22:13:30 [manu1]
We express our financial and licensing information in RDFa
22:13:43 [manu1]
our system gets this information from sites out on the Web.
22:13:54 [timbl]
All we are talking about is exposing the web bit in semantic web. What you deuce from what your computer found on the web where is you business.
22:14:23 [manu1]
yes, but "where you go something from" isn't enough.
22:14:44 [manu1]
because often, the data changes
22:14:47 [webr3]
is that not the difference between a named graph/quad and a graph literal though.. graph w/ provenance, triple w/ provenance
22:14:53 [timbl]
there is ;lots of stuff we have done wit cwm with provenance, including rules basd on who said what, and digital signature to make it secure etc etc. But just tracking where data came from in a qud store is a sine qua non.
22:15:05 [manu1]
and naming where you got it from isn't good enough, you need more information
22:15:20 [timbl]
Of course where you got it from isn'y enough to buy a car based on it every time.
22:15:23 [manu1]
like when the triples were retrieved, digital signatures on the triples, etc.
22:15:25 [lkagal]
lkagal has quit (Quit: lkagal)
22:15:48 [timbl]
But just building an editor like tabulator, you need when soemone clicks on a cell in the diaply to go bac to the data behimnd that cell ad edit it.
22:15:49 [webr3]
timbl, can you give an example of where you'd use the why component
22:16:38 [webr3]
that's how I'd always seen why, some additional provenance, not in the linked data sense, like the line in a file that a triple was declared on or such like
22:16:41 [manu1]
timbl, I'm not asserting that you don't need to do that - you do, most certainly.
22:16:43 [timbl]
I see 111 lines in the tabulator code which do so.
22:16:54 [manu1]
timbl, however, there is a way of solving that problem where you can also solve other provenance-related problems.
22:17:15 [timbl]
tabulator.log.info('licenses:'+ statement.why+': '+ licenses)
22:17:31 [timbl]
_______
22:17:32 [timbl]
var targetdoc=selectedTd.parentNode.AJAR_statement.why;
22:17:34 [timbl]
_____
22:18:21 [presbrey]
the 4th key is for indexing/accumulating multiple graph data into the same store
22:18:49 [timbl]
The latter is saying that for the bit of diplay code (a n HTML TD wich a user cicked on) its parent node (a table row) has a pointerr to the triple which it came from. The code then addresses the document from which the triple came, to generate licencing info, find out whether the tripl ecan be edited in place, etc etc
22:18:59 [manu1]
Right, I understand.
22:19:10 [timbl]
There is code to color the screen cell by cell as a function of whether it is creative commons licenced.
22:19:54 [manu1]
right, all good things - all very important - all things that need to be supported.
22:20:22 [manu1]
my point is that is one use case - there are others, for example:
22:20:29 [timbl]
I suppose one code make it a graph call instead g.why(s,p,o) returning an array of documents RDFNodes.
22:20:56 [manu1]
How do you know that what as that provenance URL at a specific point in time?
22:20:58 [timbl]
I wonder what the 4store API gives you
22:21:06 [webr3]
manu1, I hadn't put "why" in there, because by defining it's use, for instance in terms of what RDFa needs, we may make it unusable for other use-cases - so it'd had worried me
22:21:08 [timbl]
cwm has statement.why
22:21:12 [manu1]
How can you digitally sign the graph that was retrieved via the provenance URL?
22:21:33 [manu1]
How can you tag a frozen graph with information about that graph...
22:21:59 [manu1]
and I think the way that you do that is via Graph Literals, not via a 4th item on a triple.
22:22:10 [webr3]
you skolemize to sign, you use a graph literal in the second instance
22:22:40 [timbl]
In cwm you digitally sign a document which was retreived by usining log:contents and the crpto:sign etc builtin functions.
22:23:01 [timbl]
No, you don't sign the graph - you sign the orginal document,
22:23:11 [manu1]
ahh, but we need to sign the graph
22:23:17 [webr3]
manu1, why?
22:23:22 [manu1]
we don't care about what was in the original document.
22:23:34 [manu1]
because it's the graph that matters, not the containing document.
22:23:40 [manu1]
one sec, let me find an example.
22:23:46 [webr3]
so two conneged variants have same signature you mean?
22:23:52 [webr3]
- 4th item in the triple is to add additional info, unconstrained, that you may be needing / using in certain contexts - origin in a source file, some license related to the triple, a pointer to it's source etc - correct?
22:23:56 [timbl]
But the otiginal document byte stream can be signed easily, wheras the graph you get from it has to be canonicalized
22:24:09 [timbl]
which is graph canonicalization complete.
22:24:25 [timbl]
So you just send a serialization across the net
22:24:38 [timbl]
(of course -- you can't send a raw graph)
22:24:43 [timbl]
and you sign that
22:25:32 [timbl]
{ ?G log:n3String ?S . ?S crypo:sha1 ?H } => { ?S ignedBy ?H } .
22:25:51 [manu1]
timbl, re: sign the original document byte stream - from an implementation standpoint, this is wasteful to us.
22:25:51 [timbl]
Wll, that;s the way we did it.
22:25:56 [timbl]
Theer are other ways
22:26:13 [timbl]
Canonicalization of the graph can be done in many practical cases
22:26:16 [manu1]
Right, and I completely understand why you guys did it that way, and it makes sense if you're dealing with data that doesn't change often.
22:26:42 [timbl]
So how do you sign the graoh?
22:26:47 [manu1]
however, our system deals with financial and legal data
22:27:20 [webr3]
timbl, will look at adding why, and overloading add - generally the issue i wonder about/have, is whether to be defining an API that can be used by all libs, components and advanced users, or whether to be trying to make the jquery-like api for end devs, I had hoped to do both, and that the implementation of the latter would use components from the former
22:27:20 [webr3]
(and that there may be several differen jquery-like api / libs)
22:27:31 [manu1]
We canonicalize the graph using JSON-LDs canonicalization rules: http://json-ld.org/spec/ED/20101128/
22:27:36 [manu1]
then we sign that graph
22:27:39 [timbl]
webr3, if you ass .why it should eb in a module which not everyone implements.
22:27:48 [timbl]
But I'd ike to see 4store implement it
22:27:56 [manu1]
the graph is stored as a Graph Literal, the signature and origin information are stored as properties on the Graph Literal.
22:28:07 [webr3]
timbl, glad you said that - i agree
22:28:53 [timbl]
mnu, where is the canonicalisation in that JSON-LD doc?
22:29:04 [manu1]
webr3 - good point, but I bet that if the W3C could have implemented JQuery to begin with and not the DOM API - they would've chosen to implement JQuery :)
22:29:10 [manu1]
timbl, one sec, looking for the link.
22:29:39 [manu1]
timbl - http://json-ld.org/spec/ED/20101128/#the-normalization-algorithm
22:29:46 [webr3]
manu1, i hope not, often i need the dom and jquery doesn't cut it at all, but in common cases it does - need both (im/experience/opinion)
22:30:00 [manu1]
(and don't trust the text fully, our implementation is correct... the spec isn't quite correct (lags implementation)
22:30:31 [manu1]
webr3 - what I mean is that W3C would've done the DOM API /and/ put in the proper convenience functionality to make it easy.
22:30:58 [manu1]
webr3, don't take that as "that's what we need to do" - it requires a certain amount of being able to predict the future that I am not capable of :P
22:31:01 [webr3]
manu1, ahhh - well we could take that approach, just add on a new interface for all that stuff
22:31:14 [webr3]
manu1, lol agree - hence why one didn't :p
22:31:25 [manu1]
webr3, yes - we could take that approach, not saying we will - but we should be open to it.
22:31:36 [webr3]
agree
22:31:39 [timbl]
How do you for exampel canonicalize a cube of linked bnodes?
22:32:31 [manu1]
timbl, you have to specify an Object Frame (which is another very long conversation we're having)... let me find that link.
22:32:39 [bblfish]
do you know own your @timbl twitter account?
22:33:09 [manu1]
timbl - Object Framing and Cycle Breaking - http://groups.google.com/group/json-ld/browse_frm/thread/7f9c138ab6aa07be
22:33:40 [timbl]
You can't sort the keys when they are bnodes as bnodes have arbitrary identifiers
22:34:15 [manu1]
timbl, we've looked at that issue two solutions:
22:34:19 [timbl]
bblfish, I am @timberners_lee on twtter ... i have @timbl but don't use it .. I use @timbl on identica
22:34:34 [manu1]
1) You can't digitally sign data that has bnodes (which is the approach we take in our system)
22:34:36 [webr3]
timbl, don't you expand bnodes out and loose the refs?
22:34:36 [timbl]
That's life when you don't use URIs for IDs
22:35:30 [manu1]
2) You must specify an identifier creation mechanism (start from 1, count up) for bnodes, use that.
22:35:43 [timbl]
webr3, how do you explan dthe bnodes in { _:a p _:b . _:b p _:a } ?
22:36:16 [timbl]
You can only expand a bnode which has one incoming link only -- and is not in a loop.
22:36:59 [webr3]
I hope you don't expect me to answer that question lol, other than "you can't"
22:37:00 [bblfish]
The paper descriging this is here http://www.hpl.hp.com/techreports/2003/HPL-2003-142.html
22:37:03 [timbl]
manu, if you start dfrom 1 and count up it just depedns whcih bit og the grpah you happen to grab hold of fiest
22:37:11 [timbl]
how the numbers get allocated
22:37:26 [bblfish]
"Signing RDF Graphs" by Jeremy Carroll
22:37:55 [manu1]
The basic rule is that the identifiers need to be generated in the same way, or you can't digitally sign the information.
22:38:08 [manu1]
I don't mean to purport that this is a general solution.
22:38:37 [timbl]
Yes, I think the algo he has is similar to the canonicalization I use for testing in http://www.w3.org/2000/10/swap/cant.py -- it isn't guaranteed to work but will for all the graphs I have tried it on.
22:38:38 [manu1]
It's not - but in the cases where you do need to digitally sign information, we tell people that they need to make sure that 1) There are no cycles and 2) There are no bnodes.
22:38:41 [webr3]
manu1, have you read the paper bblfish pointed to? it's a good one - some good stuff on skolem on esw as well iirc
22:39:07 [timbl]
You use all kinds of hacks to deterministically order the bndoes as a function o ftheir surroundings.
22:39:07 [manu1]
no, not yet... I'll see if anyone on our engineering team did.
22:39:32 [manu1]
right, which is why we tell people - 'don't use bnodes if you want to digitally sign your data' :)
22:39:37 [bblfish]
yes, I read it too. Not in detail, because I did not need to implement it. Though it easier to stick to signing representations
22:39:37 [timbl]
Ah -- if you have no bnodes thenit is easy.
22:39:56 [manu1]
timbl, yes - but that's the point - constrain the input so the problem becomes easy.
22:40:06 [timbl]
But in fact manu they can use bnodes if they just sign the message as it is serializsed.
22:40:36 [timbl]
Which for some application will wok nciely, particularly those where the garph is sent as a messgae anyway between the parties
22:40:37 [manu1]
timbl, assuming that the bnode identifiers are generated in the same manner on the sender and the receiver, yes.
22:40:50 [manu1]
timbl, exactly right!
22:40:59 [timbl]
you can't in general make an algo to assure that
22:41:10 [webr3]
tis a good point.. signing the messages has lots of other uses as well.. as you can match signature to the source to verify it
22:41:24 [timbl]
You can use XML Digital Signature
22:41:31 [timbl]
Or just to the math on it
22:42:07 [manu1]
timbl, which is why it works for us - we're defining the PaySwarm protocol - we say "this is what you have to digitally sign, and you do it in this way - no bnodes, no cycles. If there are cycles, here is the expected structure of the graph (via Object Framing)"
22:43:04 [timbl]
Cycles are not a problem.
22:43:11 [timbl]
Only bnode numbering
22:43:12 [manu1]
Another option is that if you're in control of how the graph is generated each and every time, you can have bnodes and digitally sign and check your signature later.
22:43:32 [manu1]
timbl, I disagree, cycles became a big problem for us.
22:43:43 [timbl]
cant.py above numbers teh bnodes repeatably
22:43:45 [webr3]
manu1, if you store the message as provenance, than you can check signature on that at any time..
22:43:50 [timbl]
for most practical graphs
22:44:08 [timbl]
manu, why are cycles a problemw hne signing?
22:44:30 [manu1]
timbl, because cycles affect serialization
22:44:41 [webr3]
timbl, they only are when you're in json object/tree structure and the cycles can be in any roder, producing same graph
22:44:46 [webr3]
order*
22:44:53 [timbl]
If you have a set of statements with no bnodes
22:44:58 [webr3]
in ntriples, turtle etc, it's not a problem
22:45:01 [timbl]
Then you hash each statemnt
22:45:03 [manu1]
correct
22:45:20 [melvster]
melvster has quit (Remote host closed the connection)
22:45:25 [timbl]
Then you xor the hashes then you have a hash of the graph whioch is independent of the order of the statements
22:45:40 [melvster]
melvster (~melvster@p5797FB4B.dip.t-dialin.net) has joined #dig
22:45:50 [webr3]
timbl, yes - if no bnodes
22:46:05 [timbl]
That's why I said if no bnodes then loops not a problem
22:46:14 [manu1]
or if you have a bnode ordering algorithm.
22:46:36 [manu1]
s/bnode ordering algorithm/bnode identification assignment algorithm that is shared between all implementations performing the digital signature/
22:46:44 [webr3]
manu1, I'm unsure why you are going for a sig on the structure of a serialization, rather than sign the canonicalized triples or the message
22:47:01 [timbl]
Carlos ____ visited CSAIL and did some work making hashes of graphs to speed up the inference engine in a world of heavily nested graphs.
22:47:04 [webr3]
you're binding your app to jsonld
22:47:05 [manu1]
webr3, possible miscommunication
22:47:22 [manu1]
webr3, we are digitally signing the canonicalization of the triples.
22:47:22 [webr3]
timbl, pointer?
22:47:36 [timbl]
Hmmmmm
22:47:41 [manu1]
webr3, we're normalizaing/canonicalizing and then signing.
22:47:46 [manu1]
or rather
22:47:53 [webr3]
manu1, nah you're signing an canonical object view on to a graph
22:47:57 [manu1]
webr3, we're canonicalizing, hashing and signing the hash.
22:48:01 [webr3]
rather than say, ntriples
22:49:01 [manu1]
gah, out of time - I definitely want to pick this discussion up later...
22:49:31 [manu1]
webr3 I'll ping you about this at some point in the future... perhaps we should be doing what you're saying - I just need to figure out if we're understanding each other correctly.
22:50:11 [manu1]
also need to make sure I read Jeremy Carroll's paper - I think I did, but will have to make sure
22:50:18 [bblfish]
that's an interesting trick that hash signature one.
22:50:57 [timbl]
:)
22:50:58 [manu1]
gtg, thanks for the chat all - will be in touch with what we find. We have to solve this problem in an easy way for JSON-LD and PaySwarm work.
22:51:17 [webr3]
enjoy, speak soon :)
22:51:30 [webr3]
manu, ps did you see tag about issue 120?
22:51:41 [manu1]
not yet, no
22:51:43 [manu1]
link?
22:52:15 [webr3]
http://lists.w3.org/Archives/Public/www-tag/2011Jan/0053.html and http://lists.w3.org/Archives/Public/www-tag/2011Jan/0054.html
23:07:07 [kennyluck]
kennyluck (~kennyluck@2001:200:1c0:3602:225:ff:fe4d:f8c7) has joined #dig
23:13:00 [Pipian_]
webr3, manu1, sorry I didn't get back to you, was in a meeting, so I didn't get to see the big discussion on GraphLiterals.
23:13:07 [Pipian_]
And other API stuff
23:13:53 [webr3]
np, can you expand on your specific question, then maybe one can help more
23:14:23 [danbri]
danbri has quit (Remote host closed the connection)
23:14:59 [Pipian_]
I see that with a GraphLiteral, you're (sort of) going for an immutable graph.
23:15:06 [Pipian_]
I guess my question is that
23:15:36 [Pipian_]
Since I'm storing the triples in a durable graph in indexedDB
23:16:06 [Pipian_]
I need to make some sort of decision as to when a graph created via createGraph is actually durable
23:16:08 [Pipian_]
And when it's not.
23:16:49 [Pipian_]
i.e. some sort of standard as to when a graph is actually saved and changes made to it are stored
23:16:58 [Pipian_]
Versus not actually being saved (i.e. transient)
23:17:27 [Pipian_]
When should a graph be transferred (essentially) from in-memory use
23:17:33 [Pipian_]
To in-indexedDB use.
23:19:30 [Pipian_]
And, if I'm going to use indexedDB as a quad-store, then I also have to use unique identifiers for each GraphLiteral as if it was a bnode.
23:20:50 [Pipian_]
So figuring out the extension to the API to transfer it into and out of memory or the indexedDB store...
23:21:02 [Pipian_]
That's important too.
23:21:35 [amy]
amy has quit (Quit: This computer has gone to sleep)
23:22:03 [webr3]
Pipian, formerly we had thought different graph interface implementations for different features, like an automagically persited graph in one case, and in the other then add the graph to a TripleStore, GraphStore or QuadStore - there's a mail on the distinction we drew, will find it
23:22:30 [Pipian_]
Yeah, I think I saw some of that conversation.
23:23:01 [webr3]
-> http://lists.w3.org/Archives/Public/public-rdfa-wg/2010Nov/0029.html was one
23:23:15 [webr3]
and did you read post that manu pointed you to earlier?
23:23:21 [Pipian_]
Yeah
23:23:54 [Pipian_]
I mean, perhaps the solution is to just extend the environment to store and retrieve graphs from it
23:24:05 [Pipian_]
Rather than actually implementing that stuff in the graph.
23:24:12 [webr3]
as opposed to passing the graphs to and from a store?
23:24:27 [Pipian_]
Or the environment could have createStore(), yes.
23:24:56 [Pipian_]
Right now, I'm creating one environment per indexedDB store
23:25:10 [Pipian_]
But it could be the other way around (create stores from indexedDB)
23:25:17 [Pipian_]
*from the environment)
23:25:44 [Pipian_]
Although in some sense they're independent of each other
23:25:55 [Pipian_]
It's not like the store cares about the term/prefix maps
23:26:06 [Pipian_]
Or when anything other than a graph is created or changed.
23:27:09 [webr3]
indeed, so I guess you'd be looking for, store.createGraph adn then have the graph interface returned with augmented methods like .update or .persist - or better yet, automagically persisted
23:27:11 [Pipian_]
So maybe a createGraphStore(name) is what I should extend the environment with instead.
23:27:30 [Pipian_]
Yeah. Probably.
23:27:36 [webr3]
store.createGraph(name) ?
23:27:46 [Pipian_]
That could work as well.
23:28:38 [Pipian_]
At which point creating a store can just be done from the environment, I suppose, although that doesn't strike me as particularly relevant.
23:28:59 [Pipian_]
(graphStore needs a name too, if it's going to open up an indexedDB)
23:29:24 [webr3]
so a graph store holds multiple graphs, or one store per graph?
23:29:40 [Pipian_]
The former
23:29:57 [Pipian_]
Although I'm realizing
23:30:21 [Pipian_]
If indexedDB is my backend, and I'm going to implement most of the graph functions on top of it
23:30:39 [Pipian_]
I should probably just have every graph be persistent
23:30:53 [Pipian_]
And worry about non-persistent versions later.
23:31:26 [webr3]
can you do that / is it wise? what about graph.filter for instance, it returns a new graph, normally temporary, unnamed, would that be persisted too?
23:31:45 [Pipian_]
Oh, well, this is first iteration.
23:32:01 [Pipian_]
Obviously having everything be persisted automatically in all circumstances is poor design choice.
23:32:43 [Pipian_]
But at least for the first iteration, yes.
23:33:01 [webr3]
cool - it's good to have the option of persisting everything :)
23:33:10 [webr3]
means you can close browser, reopen, and continue!
23:33:18 [webr3]
what lang are you in btw, js in browser?
23:34:36 [Pipian_]
Yeah.
23:34:48 [Pipian_]
firefox 4b10 is where I'm testing this.
23:35:42 [webr3]
is the code available? given I've done and am doing the same implementations in js, we should probably use each others code for things, should be interop from the get go
23:35:53 [webr3]
eg I've got parsers / serializers etc you can be using
23:36:11 [Pipian_]
Hoping to put it up here pretty soon once I get graphs and graphliterals supported.
23:36:16 [Pipian_]
So some time next week.
23:36:25 [Pipian_]
It's got unit tests and documentation too.
23:36:36 [webr3]
and no bugs w/ api? :o
23:37:01 [webr3]
that's great btw (releasing code), I should have had my version released already for the new api, but been swamped of late
23:37:13 [kennyluck]
kennyluck has quit (Quit: kennyluck)
23:37:25 [Pipian_]
Well, it probably has bugs due to doing some back-of-the-hand coding here rather than studying the spec at length.
23:37:32 [Pipian_]
But any API bugs can probably be resolved quickly.
23:37:35 [kennyluck]
kennyluck (~kennyluck@2001:200:1c0:3602:225:ff:fe4d:f8c7) has joined #dig
23:38:10 [webr3]
cool :) be v glad to have a persistant store for this too
23:38:16 [webr3]
danbri has been after one for ever!
23:38:33 [webr3]
(and sparql in js)
23:40:01 [Pipian_]
Will keep you informed. Like I said, probably some time next week once I code up the graphs and graph literals
23:40:03 [Pipian_]
Speaking of which
23:40:18 [Pipian_]
It's not stated how toString() and toNT() should work on a graphLiteral
23:40:58 [Pipian_]
And being a sub-interface of Literal doesn't make much sense either I guess?
23:41:20 [webr3]
lol indeed, not sure I/we could get away with putting that in the spec since even graph literals and the generalized triples are causing a huge fuss - "it's not in RDF!"
23:41:33 [webr3]
by gut reaction though, is just the same as AIR and N3
23:41:42 [webr3]
typical quoted graph {}
23:42:15 [Pipian_]
That's what I'm inclined to say.
23:42:31 [webr3]
sub interface of literal was from timbl, and the question what's the datatype of a graph? if it has a datatype then it's a literal
23:42:49 [webr3]
and it's not a named/unnamed node, so must be i guess
23:43:38 [Pipian_]
I guess so.
23:44:07 [webr3]
s/quite/quick +spec
23:44:27 [webr3]
ericP, that's one you may be interested in? or I'd like to know your gut reaction to that
23:44:28 [Pipian_]
Basically
23:44:40 [Pipian_]
N3 - property paths - variables
23:46:15 [Pipian_]
And minus rules.
23:47:22 [Pipian_]
Only thing that's ever bothered me about the formulae in N3
23:47:41 [Pipian_]
Is that there's no accepted way to bridge the gap between formulae and named graphs right now.
23:48:04 [Pipian_]
I guess you could use owl:sameAs but...?
23:49:19 [Pipian_]
I've always sorta ended up concluding that Formulas are just anonymous-graphs. The bnode to the named-graph's URI.
23:49:53 [webr3]
:) I've been thinking a lot about that recently
23:50:54 [Pipian_]
And I guess the latter thought means the former would work fine?
23:51:04 [webr3]
essentially you need some kind of alias property, where when encountered swaps the ref for the object - could be used with subject as literals too - <uri> :alias 34 ; :gt 33 . == 34 :gt 33
23:51:05 [webr3]
?
23:51:09 [Pipian_]
I mean, if you said _:a owl:sameAs <http://example.com/> .
23:51:25 [Pipian_]
You're effectively assigning a name to _:a anyway.
23:52:05 [Pipian_]
I mean, granted, you're bending owl:sameAs semantics a bit far
23:52:19 [Pipian_]
Since I think it assumes it has two resources rather than (say) a graph or literal.
23:52:47 [webr3]
there's got to be a combo of the owl properties one could use to make this property - not sure sameas cust it
23:54:46 [Pipian_]
I mean, yeah, <uri> owl:sameAs "string" . almost certainly breaks some assumptions (not to mention reasoners)
23:55:12 [webr3]
perhaps there's just a missing property..?
23:55:34 [Pipian_]
I would say so.
23:55:47 [Pipian_]
An alias property, like you said.
23:55:51 [Pipian_]
Also, for a datatype?
23:55:57 [Pipian_]
rdfg:Graph?
23:56:19 [Pipian_]
Although that fails to encapsulate the actual string encoding!
23:56:52 [Pipian_]
(Is the literal representation of the graph N3? RDF/XML? RDFa?)
23:56:53 [webr3]
probably need to spec it, as part of aforementioned spec
23:57:12 [Pipian_]
Well
23:57:29 [Pipian_]
I'd hate to shim in graphs as datatyped literals
23:57:33 [Pipian_]
That seems a bit hokey to me.
23:57:42 [Pipian_]
It seems to me that they'd do better as first-order objects.
23:57:48 [webr3]
agree
23:58:19 [Pipian_]
Anyway
23:58:22 [Pipian_]
I gotta get going
23:58:30 [webr3]
cool - good talking
23:58:36 [Pipian_]
I'll probably have something to say about the implementation next week.