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

Re: Complexity of RDFa

From: Bob DuCharme <bob@snee.com>
Date: Wed, 31 Mar 2010 11:27:35 -0400
Message-ID: <4BB369E7.7040704@snee.com>
To: "Hondros, Constantine" <Constantine.Hondros@wolterskluwer.com>
CC: "public-rdfa@w3.org" <public-rdfa@w3.org>
Hi Constantine,

I've always felt that the W3C RDFa examples that show markup embedded in 
prose discussions of upcoming picnics were going to give the wrong 
impression about how easy it would be to automate the insertion of this 
markup. A lot of the ASP, PHP, and JSP programmers are reading data from 
relational databases and generating HTML tables on the fly (e.g. airline 
and theater schedules) and adding extra attributes and/or wrapper 
elements within the rows of those tables to show which td element has 
the start time and which has the price is very little trouble.

I suppose I understand the attitude of not wanting to clutter up their 
output with new stuff for this new application, and wanting to put it 
into a header instead, but like the class attribute that their code 
would have added to provide hooks to a CSS stylesheet, RDFa adds 
semantics that can provide hooks to all kinds of applications, so I 
think it's worth it.

Bob

Hondros, Constantine wrote:
> 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 Wednesday, 31 March 2010 15:28:13 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 31 March 2010 15:28:14 GMT