Re: Compact forms of language literals

Hi Ivan,

2011/9/13 Ivan Herman <ivan@w3.org>:
> Niklas,
>
> On Sep 13, 2011, at 11:57 , Niklas Lindström wrote:
>
>> 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 am not sure I understand. Isn't perfectly o.k. to put a @context with, possibly, a single language setting on the top? That would be valid for all children, ie, it will play exactly the same role as @xml:lang on the root.
>
> What do I miss?

Absolutely, in itself that's just fine. But, at least in my scenarios,
my context is quite large, and hence I prefer the external reference
form, i.e.:

  {
    "@context": "/api/context.json",
    "@subject": ...
  }

If @language can only be put in the context *and* I want to use
@language with different values for different documents, I'd have to
do e.g.:

  {
    "@context": "/api/context.sv.json",
    "@subject": ...
  }

, i.e. have different context documents per language. Or, granted,
make do with one primary language for my app, and have all other
language literals use the verbose form.

Here's my perspective: In one of the scenarios I work with, we have
course descriptions with titles and descriptions in at least both
swedish and english (sometimes several more). There's one HTML page
per language. For the underlying JSON to reflect this, and be easily
used, I'd like to provide one "/course/123/event/XYZ.en.json" and one
ending in ".sv.json". I'd prefer to use a short form for the values of
title and description (so that consumers won't have to filter the
values for the one matching their preferred language). But I'd also
prefer having them link the same JSON-LD context (to reduce
consumption woes and to keep the context document static).

This may be a separate issue though: "Should @language (and @base) be
possible to vary independent of context". That is, let's make ISSUE-29
be about supporting @language in @context, and raise a separate one
about this varying, if there's interest.

Best regards,
Niklas



> Ivan
>
>
>>
>> (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
>>
>>

Received on Tuesday, 13 September 2011 11:23:16 UTC