Re: Expansion Algorithm

On 12/05/2011 01:10 PM, Gregg Kellogg wrote:
> I think we're in danger of conflating two issues, and I'm not sure I understand all the nuances. Given the following (complete) JSON-LD doc:
>
> {
>    "@context": { "age": "http::/xmlns.com/foaf/0.1/age" },
>    "age": 54
> }
>
> How is this expanded, and how is this normalized? If it is expanded to the following:
>
> {
>    "http://xmlns.com/foaf/0.1/age": {
>      "@literal": "54",
>      "@datatype": "http://www.w3.org/2001/XMLSchema#integer"
>    }
> }
>
> Then we need to use an implied xsd:integer type, where this prefix is never declared by the user and forces us to define JSON-LD primitive types in terms of XSD. This is why I suggested that the expanded form should continue to use the native datatype representation:
>
> {
>    "http://xmlns.com/foaf/0.1/age": 54
> }

The problem with that representation is that the datatype is unknown. Is 
54 an integer or a double? Is it an unsigned integer or a signed 
integer? Is it just a "number"?

I think expanded form should be regular and explicit with datatypes -- 
and both of these goals are accomplished with how expansion works at the 
moment. I'm not strictly opposed to using something other than XSD, but 
it seems like we would just have to introduce our own vocabulary. So why 
not reuse what's already out there?

> The point is either if foaf:homepage has a coerce rule or not, but "ex" is defined as a term that the algorithm should descend into the @iri object to expand ex:home. Looking at the spec it says nothing about expanding values where the key is "@iri". TO make this happen, we need to be clear that "@iri" is defined to have an implicit coercion rule of {"@iri": {"@datatype": "@iri"}}, which shouldn't be too much of a stretch.

Yes, I agree we should be more explicit about this in the spec. I'm in 
general agreement on your other points.

-- 
Dave Longley
CTO
Digital Bazaar, Inc.

Received on Tuesday, 6 December 2011 07:05:45 UTC