W3C home > Mailing lists > Public > public-rdf-comments@w3.org > December 2013

XMLLiteral and HTML

From: Richard Light <richard@light.demon.co.uk>
Date: Wed, 04 Dec 2013 15:39:48 +0000
Message-ID: <529F4CC4.4060800@light.demon.co.uk>
To: public-rdf-comments@w3.org

Following an interesting exchange about the fate of the RDF API [1] over 
on public-lod, I have just had a look through the RDF 1.1 Concepts CR 
document [2] to bring myself up to date on the core RDF standard.

There it is noted that the rdf:HTML and rdf:XMLLiteral datatypes may be 
made non-normative.

Although (being an XML-head) I was pleased when I discovered some time 
ago that you can validly dump chunks of XML into an RDF resource, on 
reading the spec afresh I do wonder what business chunks of XML and HTML 
have, to be floating around in the innards of an RDF graph.  Wouldn't 
the RDF model be significantly easier to implement if they were 
removed?  To support them, you presumably have to bring XML and HTML 
parsing capabilities into your core RDF engine, together with suitable 
DOMs to hold the result of parsing. I'm assuming that no-one is 
suggesting that the semantic payload of these embedded resources is in 
any way relevant to the RDF graph.

I can see that it can be argued that these are just "special string 
types", but surely there is an order of magnitude of difference between 
interpreting a date datatype from its lexical space to its lexical 
value, and parsing an XML document fragment?

Surely the natural way to associate HTML and XML resources with an RDF 
graph is to point to them with a URI?  What you could do, is to invent 
an RDF mechanism for "linked document type" which is analogous to 
datatypes for literal values.  Then you could express a node as e.g.:


and then have a loose coupling between the RDF engine and the processing 
(or not) of the linked resource.  By including a linked document type, 
you also enable the use of content negotiation, so that variant forms 
can be retrieved from the same URL.

This generalized mechanism would mean that other content types (e.g. 
JSON) could be supported without a further extension to the RDF Concepts 
recommendation being required.


[1] http://www.w3.org/TR/rdf-api/
[2] http://www.w3.org/TR/rdf11-concepts/

*Richard Light*
Received on Wednesday, 4 December 2013 15:39:36 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:29:58 UTC