Re: The rdf:JSONLiteral datatype

Dominik,

Richard emphasized that he commented as an individual and not as an official WG answer: so do I. But, for the records, I agree with Richard. Defining a specific datatype for JSON would open the floodgates to define specific datatypes for a load of other text based syntaxes. This is not the role of the RDF namespace, not the charter of this Working Group. 

I encourage you define such a datatype under a namespace that you control, but it would probably make much more sense to do it systematically for formats like CSV and others, too. If you do that, and publish it on the Web, it may get traction among developers if there is a real need for it...

Cheers

Ivan

---
Ivan Herman
Tel:+31 641044153
http://www.ivan-herman.net

(Written on mobile, sorry for brevity and misspellings...)



On 17 May 2012, at 21:49, Dominik Tomaszuk <ddooss@wp.pl> wrote:

> 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 Friday, 18 May 2012 04:23:41 UTC