- markup (76)
- xml (11)
- xslt (23)
- pipelines (8)
- atom (9)
- overlapping markup (6)
- schema (11)
- creole (5)
- dtll (1)
- xforms (1)
- xpath (1)
- xquery (2)
- coding (2)
- datagovuk (1)
- genealogy (4)
- hardware (1)
- linked data (15)
- named graphs (1)
- opendata (1)
- psi (3)
- skos (1)
- sparql (4)
- Talis (7)
- unicode (1)
- uri (4)
- versioning (1)
- visualisation (6)
- web (77)
- google (4)
- html5 (5)
- jQuery (2)
- rdf (45)
- ontologies (2)
- rdfa (8)
- rdfQuery (5)
- rest (6)
- wikis (1)
- work (3)
- legislation (2)
- xmlsummerschool09 (2)
- life (28)
- children (5)
- equality (6)
- gtd (1)
- environment (4)
- gadgets (5)
- software (3)
- xlinq (2)
- conferences (11)
- ukgc09 (1)
- xtech (9)
- xtech2008 (3)
- blog (8)
- drupal (3)
Re: RDFa, sure, but now?
My impression is that RDFa is close enough to done to be relatively low risk, although personally I’d like to see a little more documentation of the recognition/interpretation mechanism(s). If I wanted to use RDFa right now I’d go belts and braces and reference a GRDDL profile/transformation (there’s an RDFa2RDFXML.xsl linked from the GRDDL Primer) so even if there were radical changes with RDFa, the document would still be interpretable as RDF.
eRDF (with GRDDL) seems to be stable - at this point in time it’d be my own first choice where flexibility of the data embedded is a requirement.
It depends quite a lot on what’s going to be embedded. If it’s going to be the same kind of stuff throughout a lot of documents, using microformats and/or plain-old custom class names (like a locally-defined microformat) would probably be a good choice, though someone would have to write the GRDDL XSLT (I wonder who :-)
Multiple profiles can be applied to a doc with GRDDL, and generally the different approaches can be used together without side effects.
(heh, the captcha I just got seems appropriate “depth choice”)