Re: The rdf:JSONLiteral datatype

On 17 May 2012, at 20:12, Dominik Tomaszuk wrote:
>>>>  • What is the use case for this datatype?
>>> 
>>> Repository of access control, where we store ACLs in JSON for RDF data.
>> 
>> Wouldn't it be better to define a my:JSON_ACL datatype for your specific JSON format?
> 
> That's what I do now.

Good! :-)

> JSON is data serialization oriented markup language

(Nitpick: JSON is *not* a markup language.)

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

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

Best,
Richard

Received on Thursday, 17 May 2012 19:35:19 UTC