RE: JSON-LD Comments

Hi Nathan,

thanks a lot for the feedback!

> 1) I personally find keyword @type to be very confusing/overloaded,
> when
> considering the usage of the word in RDF, it appears that @datatype may
> be more accurate in most cases within JSON-LD

We had quite some discussions about this but concluded that for the primary
target group, i.e., average Web developers it is more confusing to have two
separate keywords. Look at it from a programmer's perspective. You define
variables the same way, independent of whether they are objects or
primitives. I agree that the spec could be improved in explaining this and
I'm currently working on that (and a slight reorganization of the spec to
remove some of the unnecessary repetitions).


> 2) @language, it may be good to align with RDF concepts to say that
> it's
> value must be "a non-empty language tag as defined by [BCP47]. The
> language tag must be well-formed according to section 2.2.9 of [BCP47],
> and must be normalized to lowercase."

I added [1] the note about being well-formed but I don't think we need to
require developers to lowercase it. We can take care of that in the API - in
fact we already specify that in the API spec [2]

 
> 3) "It is also possible to override the default language or specify a
> plain value by omitting the @language tag or setting it to null" -
> setting it to null makes sense, using @value and omitting @language
> seems like unexpected functionality to me and a big potential gotcha.

So you would argue that the default language should also apply to things
like { "@value": "Hi" }
I don't have a strong opinion about this but think it makes sense to *not*
apply it in this case. The same applies to type coercions. Otherwise you
might end up having to define something like

  { "@value": "Hi", "@language": null, "@type": null }

If you don't have control over the context and have to make sure that it
will be an untyped literal without language tag.


> 4) "typed values or values that are subject to type coercion won't be
> language tagged." what is they are type coerced to, or have a type of,
> rdf:langString?

Type coerced values are values where you specify a @type in the context. For
example

{
  "@context": { 
    ...
    "@language": "en",
    "date": { "@id": "ex:date", "@type": "xsd:dateTime" }
  },
  "date": "2012-06-15";
  ...
}

This would result in

 _:b1 ex:date "2012-06-15"^^xsd:dateTime

And the default language would of course not apply to such values.



> 5) I can't seem to find any guidance on using both @container and
> @type,
> or @container and @language, within a context? Although one example
> does
> include both @type and @container

You mean using @type and @container for the same property, but not
"@container": "@type", right? You are right, this is not explicitly
described in the spec. The idea of @container is more or less just to define
whether an array is an ordered list or a set, it has no other effects.. well
almost, if used in compaction it will also ensure that the result remains an
array even if there's just one entry.

Do you think that needs further explanation?


> 6) I can't seem to find where the spec defines valid values for
> @container (i.e. that it MUST be @list or @set)

Look at the JSON-LD Authoring Guidelines section, point 9.2 [3] (was called
Grammar before and still needs some work).


> 7) 4.1 Typed Values - trimmed quote:
> ""
>    "age": 31
> 
>    The example above is really just a shorthand for the following:
> 
>    "age":
>    {
>      "@value": "31",
>      "@type": "http://www.w3.org/2001/XMLSchema#integer"
>    }
> ""
> I can't see how that's true, javascript number isn't equivalent to
> xsd:integer, IIRC it corresponds to xsd:double (the 64 bit IEEE 754),
> and would need coerced to xsd:integer (or any of the other types
> derived
> from xsd:decimal)

I wonder this was still in there. I removed it [4]. The reason why it is
still in there is that that was the way it worked before. We moved that
automatic typing to the fromRDF()/toRDF() algorithms in the API spec [5].
Basically we coerce numbers to xsd:double if the value contains a fractional
and/or an exponential component and otherwise to xsd:integer.


> 8) 4.5 Expanded Term Definition - it would be clarifying/useful to see
> the equivalent turtle for the examples in this section.

I planned to merge that section with the relevant other sections (string
i18n, typing, etc.) which should make it much clearer.


> 9) 4.7 IRI Expansion - quote:
> ""
> {
>    "@context":
>    {
>      "foaf": "http://xmlns.com/foaf/0.1/",
>      "xsd": "http://www.w3.org/2001/XMLSchema#",
>      "name": "foaf:name",
>      "foaf:age":
>      {
>        "@id": "foaf:age",
>        "@type": "xsd:integer"
>      },
>      "http://xmlns.com/foaf/0.1/homepage":
>      {
>        "@type": "@id"
>      }
>    },
>    ...
> }
> In order for the absolute IRI to match above, the absolute IRI must
> also
> be used in the JSON-LD document. Also note that foaf:homepage will not
> use the { "@type": "@id" } declaration because foaf:homepage is not the
> same as http://xmlns.com/foaf/0.1/homepage. That is, a JSON-LD
> processor
> will use direct string comparison when looking up terms in a context
> before it applies the prefix lookup mechanism.
> ""
> 
> This is very confusing, also what direct string comparison will match
> for "foaf:homepage" in the context? I can't see "foaf:homepage" in that
> @context? (even if it was in there, still v confusing / weird)

I think you already understood it but were confused that you were looking at
*just* the context. The text could definitely be improved here. The thing
is, if you have a type coercion in the context it will just match properties
in the document that use the exact same form. So in this case, it means that
in the document you would have to use the full IRI as well. A property with
the name foaf:homepage would not be coerced to an IRI here.


> May have more questions later,

More than happy to answer more questions. Hope my were helpful so far :-)


[1]
https://github.com/json-ld/json-ld.org/commit/4e3dad30321bcb2412184070402dab
c4f6eb929e
[2] http://www.json-ld.org/spec/latest/json-ld-api/#literal
[3]
http://www.json-ld.org/spec/latest/json-ld-syntax/#json-ld-authoring-guideli
nes
[4]
https://github.com/json-ld/json-ld.org/commit/9fc8cadfc6f05fbbf5d0c18216e688
b5da53949e
[5] http://www.json-ld.org/spec/latest/json-ld-api/#convert-to-rdf-algorithm



--
Markus Lanthaler
@markuslanthaler

Received on Friday, 15 June 2012 16:16:37 UTC