- From: Hondros, Constantine <Constantine.Hondros@wolterskluwer.com>
- Date: Tue, 30 Mar 2010 21:42:49 +0200
- To: "public-rdfa@w3.org" <public-rdfa@w3.org>
Thanks, but I think you run into some awkwardness if you want to go beyond a flat set of triples in the head. Toby Inkster has shown you can nest to a certain extent if you do some RDFa gymnastics (see below), but I don't think you can get away with nesting to arbitrary levels. http://lists.w3.org/Archives/Public/public-rdfa/2009Oct/0014.html I suppose what would be most convenient is a legal HTML construct within <head> that allows you to embed an arbitrarily complex wodge of RDF in it. Without it, I can see server-side developers trying to get away with sticking RDF/XML in CDATA section, or dumping N3 in a <script/> element. Or as I (and others) have done in the past, carrying RDFa in hidden <div>/<span> combinations in the body of the document. -----Original Message----- From: Mark Birbeck [mailto:mark.birbeck@webbackplane.com] Sent: 30 March 2010 18:18 To: Hondros, Constantine Cc: public-rdfa@w3.org Subject: Re: Complexity of RDFa Hi Constantine, All you have to do is put lots of meta and link elements in the head. Each would be a self-contained triple, with an @about on the element. It would look a bit like an XMLized version of NTriples. Regards, Mark On Tuesday, March 30, 2010, Hondros, Constantine <Constantine.Hondros@wolterskluwer.com> 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 Tuesday, 30 March 2010 19:43:30 UTC