Re: The rdf:JSONLiteral datatype

On 17.05.2012 21:34, Richard Cyganiak wrote:
>> and engines need to know whether the string is to be interpreted literally or parsed like JSON.
>
> I don't think the case for JSON is the same as for HTML. Once you know that a string is HTML, you know *exactly* what you can do with it. Once you know that a string is JSON, you know that it consists of key-value-pairs and lists and so on, but you don't know anything about how to process it.
>
> In REST-land, it's considered good practice to define media types for your specific JSON formats, because then a consumer knows *exactly* what the format means. This is why I think that defining your own ACL datatype (which is essentially a restricted profile of JSON with specific semantics attached) is a *better* choice than a catch-all JSON datatype.
OK, but I was compared JSON to XML, not to HTML. If you have pure 
(well-formed) XML without XML Namespaces you also don't know anything 
about how to process it. For me is the same situation like in JSON.
Moreover, in XML the most important to know how it process is XML 
Namespace. In JSON world there is more or less similar approach defined 
in [1].

>>>>>   • Given that anyone can define new RDF datatypes, why should RDF-WG do it?
>>>> Because JSON like XML and HTML is universal and common. There are a lot of solutions based on the JSON, which can be mixed with RDF in future.
>>>
>>> Well, CSS and Javascript and CSV and lots of other formats are universal and common, and have lots of solutions based on them. But this doesn't mean that RDF-WG should define datatypes for them.
>>
>> Agree. CSS and Javascript aren't neet to be RDF datatypes. But CSV (and TSV) could be considered.
>
> Well, either RDF-WG does *all* these universal/common formats, or *none* of them, or it comes up with a policy for deciding why it shouldn't do some but should do others.
>
> The status quo is that the RDF-WG plans to do *none* of them. The two that RDF-WG has already done (XML and HTML) are there for very specific reasons. RDF needs to be able to have text as literal value, and to do I18N in text properly, one needs markup (mixing multiple @lang annotations in one text, Ruby annotations, etc.) Originally it was thought that XML would completely address this, but history went in another direction, so now we needed to add HTML too.
OK, I understand your point of view.

[1] http://tools.ietf.org/html/draft-saintandre-json-namespaces-00


Best,
Dominik

> Best,
> Richard
>

Received on Thursday, 17 May 2012 19:49:48 UTC