RE: Expansion Algorithm

> 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.

But even if know the structure I might wanna take advantage of the fact that
I can use the same keys for different APIs if they can be converted to
explicit absolute IRIs. The same applies to IRI values. IRI expansion is not
a trivial job if it's done on the fly. That's why I see expansion more as a
utility function.


>> 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.

Exactly. But that doesn't have to mean that all native data types get
discarded and replaced by strings. You don't lose any information if you are
using native data types instead of typed literals.


>> 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.

You don't modify the key, you just expand ex:home in an absolute IRI. That
would mean you ignore @iri in that instance, why would you wanna do that?


>>>> 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?

Agree. We still have to define how we detect whether an IRI is an absolute
IRI or not (this should be easy as we just have to look for a colon and an
undefined prefix). We also have to define whether we allow stuff like "../"
and "./" in relative IRIs and as suffixes. Doing so would require IRI
normalization and would go beyond pure textual concatenation. I've created
ISSUE-46 for this.


--
Markus Lanthaler
@markuslanthaler

Received on Monday, 5 December 2011 04:51:37 UTC