W3C home > Mailing lists > Public > public-rdfa@w3.org > March 2010

RE: Complexity of RDFa

From: Hondros, Constantine <Constantine.Hondros@wolterskluwer.com>
Date: Tue, 30 Mar 2010 17:27:29 +0200
To: "public-rdfa@w3.org" <public-rdfa@w3.org>
Message-ID: <6C01B6D23EB50A4487054D57249A0B01097215F0BC@EUSRVWK01005.eu.wkeurope.com>
Yes, the syntax has at times made me blink hard.

Actually, I have a different issue with RDFa. It seems to have been developed from the point of view of people manually typing up html pages. The vast majority of HTML these days is spat out after some sort of server-based fusion of template and database query. ASP, PHP, and JSP programmers are pragmatic types who I suspect would like to be able to dump out a pages RDF content somewhere near the top of the file rather than modify directives in their code that produce XHTML elements.

Agreed, of course, the original idea is to annotate the content within the page itself, and if you RDF-dump somewhere at the top of your page you will almost certainly end up duplicating some literal values. However, I think it might lower the benchmark for a lot of database publishers to start inserting RDF into their pages.

Or to put it another way ... database publishers must go to lots of effort to insert RDFa tags at the precise location in the page where any literal values are expressed, only for an RDFa-reading application to parse it right out again. Since all the info is coming out of a database anyway, why not let the page developer squirt the RDF somewhere in the file at their convenience?

From: public-rdfa-request@w3.org [mailto:public-rdfa-request@w3.org] On Behalf Of Rob Vesse
Sent: 29 March 2010 14:19
To: public-rdfa@w3.org
Subject: Complexity of RDFa

Hi all

So following up on a discussion I had with Manu via Twitter I just want to raise the following couple of points about my opinions on RDFa.

My main issue with RDFa is that like RDF/XML it lets you state the same thing in a lot of different ways.  While this may be somewhat necessary when the aim is to provide a format that can be embedded inside XHTML and HTML which themselves have lots of different ways of expressing the same thing I think it makes it difficult for developers and end users to decide how best to do something.  Essentially I feel it's over complex in some ways - for example there are about 7 different ways that the subject of a triple can be set and the order & priority of these changes if there is an @rev or @rel on the element.

In some respects from a developer standpoint (in terms of parsing) this complexity is irrelevant, the rules are very clear and you can write a parser relatively quickly that can extract the RDFa from HTML/XHTML.  But from a developer standpoint in terms of embedding your RDF as RDFa inside your markup it's a lot trickier to decide how best to do this because of the many options on offer.

The other issue I raised is that while the RDF model is intended to encode machine-readable data I'd much prefer to have a concrete syntax that is also human readable e.g. Turtle.  While I can now after a year or so of staring at it far too often read RDF/XML reasonably well I have yet to stare at enough RDFa snippets to be able to do this and my feeling is that this is far harder to do because you typically have all the extra non-RDFa stuff associated with normal HTML/XHTML markup.  Manu's response to this is that any non-trivial RDFa snippet typically does require you to shove it through a parser to see what you've actually encoded which I fully appreciate and he made the point that we use already web browsers to double-check JS, HTML, CSS etc.  Yet if I write any JS, HTML, CSS etc I can easily see the intended structure and function of the markup/code even if I have to run it through my web browser to show up any typos, bugs, glitches etc whereas with RDFa I don't feel I can do this in quite the same way.

Perhaps this may just be a case of not having worked with RDFa for long enough to feel truly comfortable with it - what do other people in the community think?

Rob Vesse

PhD Student
IAM Group
Bay 20, Room 4027, Building 32
Electronics & Computer Science
University of Southampton
SO17 1BJ

This email and any attachments may contain confidential or privileged information
and is intended for the addressee only. If you are not the intended recipient, please
immediately notify us by email or telephone and delete the original email and attachments
without using, disseminating or reproducing its contents to anyone other than the intended
recipient. Wolters Kluwer shall not be liable for the incorrect or incomplete transmission of
of this email or any attachments, nor for unauthorized use by its employees.

Wolters Kluwer nv has its registered address in Alphen aan den Rijn, The Netherlands, and is registered
with the Trade Registry of the Dutch Chamber of Commerce under number 33202517.
Received on Tuesday, 30 March 2010 15:28:08 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:15:05 UTC