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: Mapping arbitrary JSON to XDI


Yes I was aware of the changing UUID issue. The answer I believe is not to add more information to the graph, but to work out a way to derive those UUIDs from the XDI subgraph (content addressing).
This would be deterministic, i.e. any XDI processor would come up with the same UUID.

Regarding the dictionary syntax, yes my thinking was exactly the way you explain it, i.e. I am mapping "address" to "+(address)" because it has a meaning that is local to this JSON instance only. This is true for all of JSON, because that format doesn't have a concept of globally understood structures (unless you consider JSON Schema maybe, but that's a separate thing).

I came across one situation where I wasn't sure how to map raw JSON to XDI, that is in the case of nested JSON arrays, e.g.:

{"numbers":[[1,2],[3,4]]}

This is currently being mapped as follows, basically a collection within a collection:

$(+(numbers))$(1a365db6-2590-41aa-9bbd-8bd6023a0fdf)$!(!8ad45ca3-cb8d-4667-ada5-01edda5917cf)/!/(data:,4)
$(+(numbers))$(1a365db6-2590-41aa-9bbd-8bd6023a0fdf)$!(!931112c7-09c6-49e5-bbb0-21ebeef90d05)/!/(data:,3)
$(+(numbers))$(a54e3dcf-7a55-4219-85ba-799e5d4aa3dd)$!(!572b5b92-fd19-48ff-94e9-5ca1baecc6bf)/!/(data:,2)
$(+(numbers))$(a54e3dcf-7a55-4219-85ba-799e5d4aa3dd)$!(!d91e9477-950c-4cfe-8b97-330c766c8174)/!/(data:,1)

I am thinking it would be nice to write up this raw JSON->XDI mapping as a non-normative proposal..
Again, the main motivation is to make it easier to write XDI connectors for JSON-based APIs.

Markus

On Fri, Dec 14, 2012 at 3:50 PM, Drummond Reed <drummond@connect.me> wrote:
Markus, this is another awesome utility. Automatic JSON --> XDI mapping.

In looking through the examples I realize it works because:
  1. All JSON object key values are valid XRIs.
  2. In collections with multiple members, the members can be identified with UUIDs.
On that latter point, the mapping isn't persistent, i.e., each time you do the conversion you'll get a different UUID. So I think you might want to put this UUID value into a special context such as $temp or $rand to each of them so that an XDI processor knows it is not an i-number that it can expect to produce a persistent mapping.

This same approach, BTW, is what I was thinking for how to map RDF into XDI. That should be pretty easy for the same reason. It's going the other way (XDI --> RDF) that will be more challenging (but should be doable once we map out all the rules).

=Drummond 


On Fri, Dec 14, 2012 at 8:20 AM, Markus Sabadello <markus.sabadello@xdi.org> wrote:
In order to be able to map non-XDI data sources such as Facebook, Google Calendar, etc. to XDI, I am thinking it would be useful to have a generic JSON->XDI mapping ability, because that's the format that most of these APIs are based on.

So I played with this a bit, you can go to

Select "RAW JSON" as the input format, and try sample 5 or sample 6 or any other JSON format.

Markus

--
You received this message because you are subscribed to the Google Groups "XDI2" group.
To post to this group, send email to xdi2@googlegroups.com.
To unsubscribe from this group, send email to xdi2+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

--
You received this message because you are subscribed to the Google Groups "XDI2" group.
To post to this group, send email to xdi2@googlegroups.com.
To unsubscribe from this group, send email to xdi2+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 






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