Re: Compact forms of language literals

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?

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


----
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 10:02:57 UTC