Re: Compact forms of language literals

I agree that it seems more natural and compact to put top-level
language in "@context", and I support that option as well.

However, it may present some problems for publishers and consumers. If
there are texts in many languages for resources, you may want to
present one JSON document per language per resource (e.g.
"/item/one.en.json", "/item/two.sv.json"). This would require one to
either inline the entire context per resource (cumbersome), or create
multiple context documents, one per language ("/api/context.en.json",
"/api/context.sv.json"...), with the only difference being just the
language value. Generating that is probably not such a big deal for a
publisher, but it may be for a consumer (and for documenting the API).

A counter-argument could be that if there are many different
languages, it makes less sense to use "@language" at the top level,
and that the verbose form of text literals should be used. Speaking
against that again would be that if there are that many different
languages, it may make even more sense to present language-specific
versions of each resource (to keep the size down, and leaving out
redundant data for a consumer needing one specific language).
(Example: DBPedia resource descriptions.)

That is why I suggested the option put it alongside "@context" in the
top-level. It also mirrors how HTML and XML documents can provide the
language for data within them document-per-document, using
@lang/@xml:lang on the root. (It's also more isomorphic with the
suggested use of HTTP headers, if that would provide context and
language in two separate headers.)

(I was also under the impression that "@base" could be put at this
top-level, but I think I misread, partly due to what seems to be an
error in the section on "Initial Context" [1] – that should be
"@coerce", not "@context", right?)

I can make do with "only in the context" though (in the specific
scenarios I currently work with), if this reasoning doesn't persuade
anyone.


Finally, pertaining to option 2 ("langmap"), I see your concerns and
I'm fine without that. I just want to ensure that the keyword aliasing
mechanism works for "@language" and "@literal" as well? I assume so,
since the spec says: "allows all of the syntax keywords, except for
@context, to be aliased" [2].

Best regards,
Niklas

PS. For reference, in Gluon I put "profile" (its equivalent of
"@context), "lang", and "base" alongside each other due to this
reasoning.

[1]: http://json-ld.org/spec/latest/#initial-context
[2]: http://json-ld.org/spec/latest/#aliasing-keywords
[3]: http://code.google.com/p/oort/wiki/Gluon



On Mon, Sep 12, 2011 at 5:21 PM, Gregg Kellogg <gregg@kellogg-assoc.com> wrote:
> +1, I had mistakenly read the example as putting it @context, this is where it should go,
>
> Also, as with other stuff in @context, it applies through all sub-nodes, unless overridden by another definition. (@language = null might clear a setting.
>
> Gregg Kellogg
>
> Sent from my iPad
>
> On Sep 12, 2011, at 1:11 AM, "Ivan Herman" <ivan@w3.org> wrote:
>
>>
>> On Sep 11, 2011, at 23:27 , Markus Lanthaler wrote:
>>
>>>> 1. Add JSON-LD support for declaring a document-wide language
>>>> directive (within the context or at the top level, i.e. where
>>>> "@context" and the optional "@base" appear). This is for scenarios
>>>> where there is one dominant language for a given resource.
>>>>
>>>> This would enable us to use @language like this:
>>>>
>>>> {
>>>>   "@context": ...,
>>>>   "@language": "en",
>>>>   "@subject": "http://example.org/",
>>>>   "title": "The Example"
>>>> }
>>>
>>> +1 but perhaps we should move @language into the context description. The
>>> "meaning" of the document is described in the context so I think that's the
>>> place to be for the @language tag as well.
>>
>> I would also feel it more natural if this was part of the @context. It would also make it clear/clean that children of a node would inherit the language setting, just like any other contextual settings.
>>
>> Ivan
>>
>>
>>>
>>>
>>>
>>> --
>>> Markus Lanthaler
>>> @markuslanthaler
>>>
>>>
>>>
>>>
>>
>>
>> ----
>> Ivan Herman, W3C Semantic Web Activity Lead
>> Home: http://www.w3.org/People/Ivan/
>> mobile: +31-641044153
>> PGP Key: http://www.ivan-herman.net/pgpkey.html
>> FOAF: http://www.ivan-herman.net/foaf.rdf
>>
>>
>>
>>
>>
>>
>
>

Received on Tuesday, 13 September 2011 09:57:57 UTC