- 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 (16)
- modelling (1)
- named graphs (1)
- opendata (1)
- provenance (1)
- psi (3)
- skos (1)
- sparql (4)
- Talis (7)
- unicode (1)
- uri (4)
- versioning (1)
- visualisation (6)
- web (78)
- google (4)
- html5 (5)
- jQuery (2)
- rdf (46)
- 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: Evolving Standards
I agree, and I don’t.
With the change to remove property from the HTML microdata proposal, we can continue to use RDFa, albeit invalidly, with X/HTML5.
However, I’ve been looking at the triples that Philip is generating from the microdata proposal examples. The graph described when using eRDF or RDFa does not match the graph generated by Philip’s application. Not only that, but triples are generated yes, but they don’t necessarily reflect the underlying RDF model.
But what happens if something like SearchMonkey adapts to consume microdata, assuming that it can do as RDF triples and merges the data into its data stores? If there is no robustness to the microdata implementation, if all we care about is “it can generate ‘RDF triples’” then potentially we could have a polluted data store, which would then impact on all of us.
It’s about the same as cutting rain forests in Brazil, and burning coal for energy in China—we can do our own thing, but whatever good we may do, could be effectively damaged by the harm others do.