Re: Compact forms of language literals

2011/9/13 Ivan Herman <ivan@w3.org>:
> Ah, o.k., I understand your concern now. Thanks.
>
> Another possibility would be to syntactically differentiate between an imported and local context and allow them both within the same object. Something like
>
> {
>  @importcontext : "http:...",
>  @context {
>    ...
>  }
> }
>
> with the agreement that the merge of the two creates the real local context, and that the local context's entries have a higher priority. It is a slightly more general approach than what you ask for, but may be useful on its own right...

That is indeed interesting. I actually had a similar suggestion in
mind (but that'd made my earlier reply a bit too long). I can
certainly see merit in this. I had a sketch like:

  {
    "@context": {
      "@import": "/api/context.json",
      "@language": "en",
      "@base": "http://example.org/"
    }
    "@subject": ...
  }

With mechanics working like you suggest. I do expect some potential
opposition to this though. We'd have to determine if such an import
would work in externally referenced contexts as well (i.e. dealing
with the issues of chained imports and recursion). Your version
doesn't raise that issue though, but I'm not sure which form would be
preferred.

In any case, this would certainly deal with the varying of language
I'm after. And as you say, there may be more use cases in favor of an
importing mechanism (the idea has crossed my mind before). Admittedly,
we'd have to consider the increased complexity.

Best regards,
Niklas



> Ivan
>
>
> On Sep 13, 2011, at 13:22 , Niklas Lindström wrote:
>
>> 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
>>>>
>>>>
>
>
> ----
> 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 12:04:09 UTC