On literals, strings and language (was Re: Reference versus xsd:anyURI Literal in JSON-LD)

On Mon, Jul 11, 2011 at 2:21 AM, Manu Sporny <msporny@digitalbazaar.com> wrote:

> Should we do the same for "@literal" - at the moment, we use xsd:string.
> I think that the RDF Working Group just stated that "xsd:string" is the
> same as a plain literal. We could do something inline with that decision:
>
> "@context":
> {
>   "@coerce":
>   {
>      "@literal": ["foaf:name", "dc:title"]
>   }
> }
>
> This would effectively state that the context wants the output to be a
> plain literal, regardless of whether or not language information or
> datatype information is specified. I don't necessarily like this as it
> could end up making data /less/ specific. The previous features which
> add @iri coercion and @datatype coercion would work in the opposite
> direction w/ @literal - removing any @iri, @language, and @datatype
> information.

This sounds like a good thing. In gluon I have used e.g.:

    "title": {"localized": true}

to define a term which should use the current language (here with the
default vocab set to "dct")..

But in my current redesign experiment I have figured that it may be
more usable in general to have JSON strings by default be interpreted
as literals with current language (if given). Then the "coerce"
mechanism can be used to turn off the language, like you suggest (kind
of similar to the parsing rules of RDFa in HTML).

That depends on JSON-LD having a way of defining the current language
for the data of course; is that so? (I believe I've missed that before
but I might have overlooked its introduction.) I'd also like to note
that it is good to be able to provide current language *along* with a
profile link (and not in the profile data itself), since it is often
useful to have different JSON representations per language while using
(linking to) the same profile. (This is just like @lang and @profile
in HTML.)

Regarding "string" or "@literal": In any case I believe avoiding
explicit use of xsd is preferable. I was thinking about a default
"import" of the xsd types as tokens. Or at least the subset of types
which JSON natively supports (along the lines of what Markus and Gregg
discuss). Then "coerce": "string" should do fine, as long as we take
that to mean plain literal without language and (explicit) datatype.
(If for some reason "xsd:string" would prove needed as distinct from
those, "@literal" might be better. But in light of the RDF WG
recommendation it seems clear that those two forms are now meant to be
the same.)

Finally, it'd like to to mention that I've found the notion of a
"language map" useful in various places, both in object/RDF mappers
and in Gluon. It might be interesting to consider if JSON-LD could
support that, along the lines of:

  "@context": { "@coerce": { "@langmap": ["title"} } }
  {
    "@iri": "/doc/the_title",
    "title": {"en": "The Title", "sv": "Titeln"}
  }


Best regards,
Niklas

Received on Monday, 11 July 2011 18:43:19 UTC