OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

xdi message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Re: Bill's question on addressing inside a literal (was: EUREKA!!!(Or, in current lingo, OMG!!!) New XDI JSON serialization format


On Fri, Apr 1, 2011 at 7:06 AM, Barnhill, William [USA] <barnhill_william@bah.com> wrote:
Drummond,
 
Your thoughts on literal addressing make perfect sense, and I've been referencing the topic we discussed a while ago on using fragment identifiers for that (it's what they're for, albeit the browser's use), e.g. I have an XDI literal storing XML so then I could have an XPath URI in an Xref to address a portion of the literal in the graph, or an XPath as fragment id to retrieve just part of the literal without making any statements about it.

I like the idea of using an XRI fragment for addressing inside a literal.
 
However...that's not what I was asking about in the email.
 
What I was asking is if this XDI serialization....
{  "=bob/+friend": ["=alice", '=trent"] }
is semantically equivalent and resolution equivalent to this serialization
{  "=bob/+friend!1": "=alice", "=bob/+friend!2": "=trent" }
 
This has the advantage that the values are simple values, not arrays so are easier to store.  Having both is nice though as the array one lends itself to applying map/reduce to the distributed XDI store.

Although I agree with the goal and would like to help achieve it, the problem I see with doing this is that the second option adds information to the XDI graph that is not in the first one. The information is NOT an ordering of the values, because !1 and !2 do not express ordering (unless they are used under a $v context). But what !1 and !2 do express is a unique persistent address for the the values in the array, and that is not information that is actually present in the first XDI graph. So the two could not be equivalent.

Giovanni has proposed something similar using $n identifiers, i.e., using $1 and $2 in place of !1 and !2 in your example. The semantics in this case would simply be "first position, second position", and not indicate persistent identifiers (which !1 and !2 do). So -- I need to think about this -- but I think it might work to say that the following were semantically equivalent (and I think "resolution equivalent", though I'm still trying to remember exactly what that means):

{  "=bob/+friend": ["=alice", '=trent"] }
{  "=bob/+friend$1": "=alice", "=bob/+friend$2": "=trent" }

What do you think? And Giovanni, what do you think?

=Drummond




From: drummond.reed@gmail.com [mailto:drummond.reed@gmail.com] On Behalf Of Drummond Reed
Sent: Friday, April 01, 2011 1:45 AM
To: Barnhill, William [USA]
Cc: OASIS - XDI TC
Subject: Bill's question on addressing inside a literal (was: EUREKA!!! (Or, in current lingo, OMG!!!) New XDI JSON serialization format

On Mon, Mar 28, 2011 at 5:50 AM, Barnhill, William [USA] <barnhill_william@bah.com> wrote:

Nice work Drummond, a very interesting idea. I see it as an evolutionary path to go down from one of our early JSON formats, flattening our  {subj: {pred: [..],..},..} model to one level of keys through the use of XRIs such as =abc/() and the literal delimiter.  From an implementation perspective it is definitely easier. Also given any key you should be able to get the XRI identifier for a specific element, say the first, by appending !1, yes?  This means you could flatten it further to not have the arrays and simply be a key value store where we have the semantic value of XRI's within the keys. That would then fit nicely with the work I've been talking about in storing an XRI graph as KV pairs, where the key holds the XDI address, in a distributed hash table (DHT) such as TeleHash.

Bill, I finally got a chance to reply to this. I agree that having a way to address elements inside an XDI literal might be helpful -- but if they were XRI addressable, then they'd be in the graph, and not an XDI literal, no?

My sense is that a developer would use the XDI graph for as much addressability into the data as they want -- by "pulling" that data into the XDI graph -- and then use native addressing inside an XDI literal once they reach the actual literal.

This would suggest a clean line is always maintained between what's addressable in the global XDI graph and what's only addressable by some native addressing scheme inside an XDI literal.

Does that make sense?

=Drummond



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]