- From: Tom Heath <tom.heath@talis.com>
- Date: Mon, 29 Jun 2009 17:21:00 +0200
- To: Mark Birbeck <mark.birbeck@webbackplane.com>
- Cc: martin.hepp@ebusiness-unibw.org, Kingsley Idehen <kidehen@openlinksw.com>, public-lod@w3.org, semantic-web at W3C <semantic-web@w3c.org>
Hi Mark, 2009/6/29 Mark Birbeck <mark.birbeck@webbackplane.com>: > Hi Tom, > > On Sun, Jun 28, 2009 at 11:46 PM, Tom Heath<tom.heath@talis.com> wrote: >> Martin, >> >> 2009/6/27 Martin Hepp (UniBW) <martin.hepp@ebusiness-unibw.org>: >>> So if this "hidden div / span" approach is not feasible, we got a problem. >>> >>> The reason is that, as beautiful the idea is of using RDFa to make a) the >>> human-readable presentation and b) the machine-readable meta-data link to >>> the same literals, the problematic is it in reality once the structure of a) >>> and b) are very different. >>> >>> For very simple property-value pairs, embedding RDFa markup is no problem. >>> But if you have a bit more complexity at the conceptual level and in >>> particular if there are significant differences to the structure of the >>> presentation (e.g. in terms of granularity, ordering of elements, etc.), it >>> gets very, very messy and hard to maintain. >> >> Amen. Thank you for writing this. I completely agree. RDFa has some >> great use cases but (like any technology) has its limitations. Let's >> not oversell it. > > Mmm...you put me in a difficult position here. :) ;) > If I leap to RDFa's defence then it looks like I think it solves all > the world's problems. > > But if I remain silent, then it looks like the problem being raised is > some kind of fundamental flaw. Just in case there's any doubt, let me clarify that this isn't an anti-RDFa position from me, just trying to unpack the issue. > Ah well, let's dive in... > > First I should say that I'd be the first to agree that RDFa has > limitations. But the issue here is that I don't think the problem > raised by Martin can be classed as a limitation in the way you're > implying, Tom. > > If we go back a step, RDFa was carefully designed so that it could > carry any combination of the RDF concepts in an HTML document. In the > end we dropped reification and lists, because it didn't seem that the > RDF community itself was clear on the future of those, but they are > both easily added back if the issues were to be resolved. > > In short, it is possible to use HTML+RDFa to create complete RDF > documents, such as RDF Schemas, OWL ontologies, and so on, and the > resulting documents would be no more complex than their equivalent > RDF/XML or N3 versions, with the benefit that they can be delivered > using any of the many HTML publishing techniques currently available. Absolutely agreed. I don't dispute this at all. Though it's not really my point. See below... > But most of the discussion around RDFa relates to its other use, where > it's possible to use it to 'sprinkle' metadata into HTML documents > that are primarily aimed at human readers. By being alongside the > human-readable output, it makes the metadata easier to maintain. In some cases. It depends on the publishing architecture. What effect does it have on the maintenance cost of the layout/structural markup of the page? > And > in addition it gives the user agent the opportunity to enhance the > view of the data, by making use of the 'local' metadata. > > However, the point that Martin was getting at, is that sometimes there > is just way more data in the 'RDF view' than in the 'human view', and > that makes it very difficult to make the two align. Yes, this is exactly how I understood his point. It's also exactly why I keep banging on about us not saying that x is better than y. It's not about a limitation of RDFa as a technology (apologies if it came across that way), simply a reflection of the fact that it can be challenging to deploy in some circumstances. Again, this is context dependent, and the best solution can only be determined by examining that context. > I don't think that this is a flaw in RDFa itself, Agreed. > and I'm not convinced that there is an easy solution in the form of another > technology that would solve this. Well, such cases may justify the 303/conneg pattern. > Martin's solution seems a reasonable > one to me. > > (Although I wonder if part of the problem might be that too much > information is being provided in the RDF view, rather than using links > to other data that can be retrieved. Perhaps Michael could give an > example.) Completely agreed on this point. You'll see this approach manifested in Revyu.com, where there is redundancy in data between HTML pages for the sake of presenting human users with a more complete view (without requiring them to visit multiple pages); the same is not true of the (broadly) equivalent RDF documents, where I tried to avoid redundancy, on the basis that any SW agent worth it's salt should be able to dereference the referenced URIs to retrieve the data it needs. IIRC others disagree with my approach here (TimBL? Richard C?), but this speaks completely to the question of what is the appropriate interaction paradigm for apps built on the Web of Data. If we can understand the answers to this question then it may help guide our deployment strategies for RDFa. Cheers, Tom.
Received on Monday, 29 June 2009 15:21:42 UTC