Hi Tom,
I don't think any one RDF-in-HTML syntax would fit everybody's preferences/needs all of the time. You can of course come up with your own format and write some XSLT to make it into RDF. But I think you also have to answer 2 questions:
1. Is it worth your time to do so?
2. What might you lose by not following an established 'standard' (like RDFa or eRDF)?
If the only purpose of RDF-in-HTML is to XSLT it to RDF, then you don't lose anything, but I think there are other possibilities that standardised approaches make possible.
1. Parsers written in other languages. eRDF and RDFa have parsers in python and php - if the focus is on these standards, parsers in other languages are more likely to be written. The advantages of these over XSLT transformation include that they remove a dependency on XSLT from the toolchain, they remove a step for the developer who wants to get RDF-in-HTML data into triples in their language of choice. A custom parser may also be able to do the job a bit faster than XSLT, which might be useful in some circumstances.
2. Multiple contexts. RDF-in-HTML data has the context of the triples it can be transformed into, but also of the HTML document it is encoded in - and any other semantic html formats (eg: hAtom) that share the same document. Perhaps this is more incidental than important, but I think there might be some potential in exploiting this. Benjamin Nowack has talked, for instance, about using eRDF as a 'glue' for relating and augmenting microformats. Javascript widgets and plugins could also make use of the semantic hooks provided by RDF-in-HTML.
Also, from a semantic html evangelist point of view, is it worth the risk of confusing people to introduce a new generic RDF-in-HTML format?
For those reasons, the modular, backwards-compatible 'extensions' approach you suggest is probably a good way forward to adding features to eRDF/RDFa.
On your list proposal specifically, shouldn't you use @rel rather than @class? - you are describing the value of the @href rather than the inner text of the anchor.
Your second suggestion (to use 'subject' to declare within a particular node) is quite similar to the mechanism that ARC's eRDF parser already facilitates - using a rel=owl-sameAs linking to the external subject.
2007-04-25EDT22:50:46+00:00
#
Your second suggestion (to use 'subject' to declare within a particular node) is quite similar to the mechanism that ARC's eRDF parser already facilitates - using a rel=owl-sameAs linking to the external subject.
I'm not sure about using @rel - the microformats community have basically stopped using rel because of the semantics of it.
"The rel attribute specifies the relationship of the linked document with the current document"
The problem is we cannot explicitly say that every time we instantiate a triple subject class that we are going to be describing the relationship between the linked document and the current document. We may be describing the relationship of the linked document and another document, or the linked document and a Literal. Class is easier to style too.
Once I have some time to spare, I'll write up what I've done as a wiki page and publish it for comments on GetSemantic. Thanks for the feedback, Keith.
2007-04-26EDT09:09:16+00:00
#
"The rel attribute specifies the relationship of the linked document with the current document"
The problem is we cannot explicitly say that every time we instantiate a triple subject class that we are going to be describing the relationship between the linked document and the current document. We may be describing the relationship of the linked document and another document, or the linked document and a Literal. Class is easier to style too.
Once I have some time to spare, I'll write up what I've done as a wiki page and publish it for comments on GetSemantic. Thanks for the feedback, Keith.
eRDF's use of @rel perhaps isn't precisely that of html's (it relates document fragments rather than documents), but I think it's close enough. The @profile defines how the RDF-in-HTML should be interpreted, and arguably overrides the html spec, if you care about that kind of thing.
As for styling, the way that eRDF uses @class for every visible value, and @rel||@rev for the (invisible) @href just seems to me to be so clean and sensible that I have a hard time agreeing that @CLASS should refer to the @href rather than the inner text.
Ultimately, if you want an eRDF-based syntax to describe external subjects in detail, an attribute like @about is the cleanest way of doing it. Anything else complicates the simplicity of eRDF - which is its greatest advantage. Simplicity is hugely important for the people that have to write RDF-in-HTML, and the people that write parsers for it.
To my mind, the nearest compromise is extending eRDF to use @href in the same way as @id (descendants take the nearest ancestor as subject). This gives authors the choice to keep their html valid (only using @href on anchors), or keep their interface normal (@href on divs etc doesn't have any browser effect in current versions of xhtml).
It does of course complicate eRDF, but just a little bit.
2007-04-26EDT12:17:36+00:00
#
As for styling, the way that eRDF uses @class for every visible value, and @rel||@rev for the (invisible) @href just seems to me to be so clean and sensible that I have a hard time agreeing that @CLASS should refer to the @href rather than the inner text.
Ultimately, if you want an eRDF-based syntax to describe external subjects in detail, an attribute like @about is the cleanest way of doing it. Anything else complicates the simplicity of eRDF - which is its greatest advantage. Simplicity is hugely important for the people that have to write RDF-in-HTML, and the people that write parsers for it.
To my mind, the nearest compromise is extending eRDF to use @href in the same way as @id (descendants take the nearest ancestor as subject). This gives authors the choice to keep their html valid (only using @href on anchors), or keep their interface normal (@href on divs etc doesn't have any browser effect in current versions of xhtml).
It does of course complicate eRDF, but just a little bit.
