Re: Compact forms of language literals

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

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 11:29:53 UTC