W3C home > Mailing lists > Public > public-linked-json@w3.org > December 2011

Re: Expansion Algorithm

From: Dave Longley <dlongley@digitalbazaar.com>
Date: Sun, 04 Dec 2011 22:27:46 -0500
Message-ID: <4EDC3A32.5030408@digitalbazaar.com>
To: public-linked-json@w3.org
On 12/04/2011 09:47 PM, Markus Lanthaler wrote:
>>> 1) Does {"foaf:age": 54} cause 54 to be expanded to {"@literal": "54",
>>> "@datatype": "xsd:string}. IMO, I think that non-string types such as
>>> boolean, integer and numeric are not subject to expansion, in spite of
>>> any coercion.
>> .. but it should be expanded when normalizing a document.
>>
>> -1. I think expanded JSON-LD documents should have a fairly regular
>> form; where object values are either strings, literals, or IRIs. It is
>> the responsibility of a @context to provide the specific @datatype for a
>> number, otherwise it is unclear what that type is when a JSON-LD
>> document is in expanded form. Furthermore, this approach may complicate
>> round-tripping, may require more people to use normalization than would
>> otherwise not need it, and will complicate the normalization algorithm.
>> It feels inconsistent with the purpose of expansion in my view, which is
>> to provide all of the information you need about each object when there
>> is no context present.
> That would mean that if I receive a JSON document I would have, for
> instance, to convert all string back to integers to work with them.
> Expanding IRIs makes sense as it is very difficult to expand them on the
> fly.

Whenever you receive a JSON-LD document, and you are going to be using 
it via an object-accessor API (eg: javascript), then you are most likely 
going to either know the incoming structure and @context, or you will be 
using some combination of your own @context and framing. This means you 
will have set up your @context to coerce the @iris and @datatypes as you 
see fit anyway. If you're going to convert it into some other format to 
make use of some other API, then it shouldn't matter there either -- 
except in that a more regular form is easier to write a converter for.

> Why do we provide expansion then in the first place? What use cases do you
> see for it? If we are going to do this, the differences to a normalized
> document are too marginal IMHO.

Normalization is a much more difficult process than expansion. Expansion 
is provided so that you can construct a JSON-LD document without any 
context without having to deal with normalization. It is the easiest 
form to algorithmically construct a JSON-LD document in when given some 
other serialization input. For instance, you don't need to deal with any 
@context processing rules in order to build an expanded JSON-LD document 
when your input is a list of triples.

>>> 2) {"foaf:homepage", {"@iri": "ex:home"} should cause "ex:home" to be
>>> expanded, whether or not "foaf:homepage" is subject to  coercion
>> Agree
>>
>> I guess the point of this one is if a @coerce rule exists but the
>> document didn't follow the rule? If my understanding is correct here, I
>> agree.
> As to my understanding it means that I have something like
>
>     { "keynotdefinedincontext": { "@iri": "ex:home" } }
>
> and even though that key is not defined in the context, "ex:home" gets
> expanded into an absolute IRI. There's no rule that all keys have to be
> defined in the context.

Hmm, I don't know if I agree with that then. We might want to leave keys 
(non-IRIs) alone that don't appear in the @context. I think we need to 
be more careful with this decision since we wanted to support mixing 
regular JSON with JSON-LD.

>>> 3) {"@subject": "ex:home", "@type": "foaf:Document"} should cause both
>>> "ex:home" and "foaf:Document" to be expanded
>> Agree
>>
>> Provided that "ex" and "foaf" are defined prefixes, I agree.
> Which leads to another interesting question. What happens if they are not
> defined? Will they be interpreted as absolute IRIs? As relative ones (which
> are then expanded into absolute ones)?

If they are not defined, I think they should be treated as absolute IRIs 
since they have colons in them. For instance, what if one of them was 
"urn:mynamespace" and "urn" wasn't defined in the @context?

-- 
Dave Longley
CTO
Digital Bazaar, Inc.
Received on Monday, 5 December 2011 03:28:22 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 16:18:32 UTC