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

RE: Complexity of RDFa

From: Hondros, Constantine <Constantine.Hondros@wolterskluwer.com>
Date: Thu, 1 Apr 2010 10:46:12 +0200
To: Bob DuCharme <bob@snee.com>
CC: "public-rdfa@w3.org" <public-rdfa@w3.org>
Message-ID: <6C01B6D23EB50A4487054D57249A0B0109E603C1A3@EUSRVWK01005.eu.wkeurope.com>
Hi Bob,
I think what you say is entirely valid for marking up database-generated product listings, as in Ebay, Amazon, Best Buy. Here you probably just want to add a number of strongly-typed values using a well-known RDF vocabulary.

In the world of publishing, however, our metadata may be based on a complex domain ontology with a class hierarchy. As an example, this is (just a fragment of) the typical metadata that might be associated with an article of legislation.

<>  a cw:LawFragment;
    cw:infoClass cw:LegislationRegulation;
    ltr:referenceInformation _:b0 .
     _:b0 a ltr:ReferenceInformation;
        officialPublication <http://some.uri>;
        ltr:applicablePeriod _:b1 .
         _b:1 a ltr:ApplicablePeriod ;
            cw:startDate "2009-04-24T00:00:00+01:00"^^xsd:dateTime ;
            cw:endDate "2010-04-24T00:00:00+01:00"^^xsd:dateTime .
I see real complexity trying to represent this inline with RDFa. For example, the date literals will certainly be in the body of the document, so should I create a typed blank node in situ, and reference it from the more general metadata in the top of the document?

Probably the obvious solution is to publish and maintain the RDF info separately ... but that carries a management overhead of its own. Again, I feel it would be nice to have a permissive HTML construct in the head of a document that can accept RDF metadata of arbitrary complexity.

From: Bob DuCharme [mailto:bob@snee.com]
Sent: 31 March 2010 17:28
To: Hondros, Constantine
Cc: public-rdfa@w3.org
Subject: Re: Complexity of RDFa

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.


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> [mailto:public-rdfa-request@w3.org] On Behalf Of Rob Vesse
Sent: 29 March 2010 14:19
To: public-rdfa@w3.org<mailto: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 Thursday, 1 April 2010 08:46:51 UTC

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