Re: Expansion Algorithm

Gregg

On Dec 4, 2011, at 9:33 AM, Dave Longley wrote:

> On 12/04/2011 02:11 AM, Markus Lanthaler wrote:
>>>>> Object expansion should expand every value, not just those that have
>>>>> keys that are subject to datatype or list coercion. Some examples:
>>>> What exactly do you mean by "should expand every value"?
>>> As stated, the algorithm recurses through arrays to objects or strings,
>>> for objects, expands values of keys, only if the key is the target of a
>>> @datatype coercion in the context. Thus, if "foo" =>  "bar", and "foo"
>>> was declared with an IRI datatype, it would expand "bar" into an IRI.
>> OK, now I've understood what you meant. Thanks
>> 
>> 
>>> But, looking at the algorithm again, I think my examples are mostly
>>> covered. The remaining issues have to do with values that are not
>>> arrays or objects. Also, it should be clear that the determination of
>>> key coercion caries through to @list, @iri, @datatype and array
>>> processing.
>>> 
>>> 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.

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
}

For the normalized form, it seems clear that this will end up going through RDF, so there is no way to avoid the use of an XSD datatype, so I think it would be more similar to the former representation (minus white-space).

If, on the other hand, the first document was the following:

{
  "@context": {
    "age": {
      "@iri": "http::/xmlns.com/foaf/0.1/age",
      "@datatype": "http://www.w3.org/2001/XMLSchema#integer"
    },
  "age": 54
}

Then I can see expanding to the explicit literal case.

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

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.


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

This also requires specific coercion rules. Furthermore, expanding relative IRIs needs to be clear, because one might be relative to @base, while the other relative to @vocab". (I'm coming around to removing one, the other, or both, but we do need to think about how to resolve relative IRIs non-the-less).

>>> 4) {"foo": ["ex:bar", "ex:baz"]} should cause all or none of  ex:bar
>>> and ex:baz to be expanded, depending on coercion rules for "foo". This
>>> isn't clear now, as when doing array expansion, there's no discussion
>>> of a "closest" key.
>> If "foo" is coerced to @iri then all the array item should be expanded,
>> otherwise none.
> 
> I agree with Markus.

Yes, but the point is the spec wording that makes this clear. It might involve passing a "default datatype" to the local context in step 2.1.3, and saying something like the following in 2.1.3:

[[[
2.1.1 If the value is an array, process each item in the array recursively using this algorithm, passing a copy of the local context with "default datatype" set to the coercion rule for this key, if any.
2.1.2 If the value is an object, process the object recursively using this algorithm, passing a copy of the local context with "default datatype" set to the coercion rule for this key, if any.
2.1.3 Otherwise, determine the coercion rule from the associated key. If there is no such rule, use the "default datatype" from the current expansion context, if any. If the value should be coerced ...
]]]

Also, note that the keys "@iri", "@datatype", and "@list", at least, would NOT result in updating the default datatype. It also needs to be made clear that otherwise, if the key does not have an associated datatype, the default datatype is set to NULL.

Gregg

>>> 5) {"foo": {"@list": ["ex:bar", "ex:baz"]}, same argument as for 4).
>> Same here, just if "foo" is coerced to @iri.
> 
> I agree with Markus.
> 
> -- 
> Dave Longley
> CTO
> Digital Bazaar, Inc.
> 
>

Received on Monday, 5 December 2011 18:11:53 UTC