Re: Compact forms of language literals

My thought was to allow @context to take a list, which would allow both a remote context and an inline context at the same processing level. For example:

{
  "@context": [
    "/api/context.json",
    { "@language": "en" }
  ],
  "@subject": …
}

This avoids introducing new keywords and is a fairly straightforward modification to the current processing steps.

Gregg

On Sep 13, 2011, at 5:03 AM, Niklas Lindström wrote:

> 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 Friday, 16 September 2011 05:23:34 UTC