Re: JSON-LD Comments

Markus Lanthaler wrote:
> 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).

Fair point, and it would be a big change at this point.

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

Perfect :)

>> 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" }

yes, to all of the following:

{
  "sku": "1234HK98A",
  "name": "Egg Cup",
  "description": { "@value": "great for all kinds of eggs" }
}

As personally I feel it would be better for the following:
{
   "@context": {
     ...
     "@language": "en",
   },
  ...
  "sku": { "@value": "1234HK98A" },
  "name": { "@value": "Egg Cup" },
  "description": { "@value": "great for all kinds of eggs" }
}

to produce
  <foo> :sku "1234HK98A"@en ;
        :name "Egg Cup"@en ;
        :description "great for all kinds of eggs"@en .

As that's far more likely to result in a developer "fixing" their data 
(or @context) and sending out nicely internationalized and typed data.

Whereas the inverse, and current situation, will often result in a loss 
of internationalization data. I mean most developers would fix the above 
pretty quickly, whereas who'd "fix" the original example if it output 
this (as currently):

  <foo> :sku "1234HK98A";
        :name "Egg Cup";
        :description "great for all kinds of eggs" .

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

side nit: which would be invalid by  JSON-LD Authoring Guidelines 15.2 ?

   A. JSON-LD Authoring Guidelines
   15. For each JSON object that contains a @value key:
     2. It MUST NOT contain both the @language and @type keys at the 
same time.


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

Yes, just a line somewhere which states that when @type is used in 
conjunction with @container then it specifies the default type for all 
elements in a corresponding container, and similarly for @lang.

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

Ahh yes, thanks :)

minor note, does it need a 9.5 that precludes specifying both @type and 
@lang at the same time?

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

Ahh that's what I was worried about.. You see I'd quite like to create 
contexts which set the appropriate @type's for properties, so that other 
people can import them. AFAICT this would render such contexts pretty 
much useless to anybody who was using terms and prefixes in their own 
context. Make sense?

Thanks for all the replies, anything I've not responded to just class as 
me being happy w/ your response :)

Nathan

>> 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 17:48:00 UTC