- From: Niklas Lindström <lindstream@gmail.com>
- Date: Mon, 11 Jul 2011 20:42:29 +0200
- To: Manu Sporny <msporny@digitalbazaar.com>
- Cc: public-linked-json@w3.org
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