- 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: What You Can't Do with HTML5 Microdata
I don’t agree with your approach to this at all, but I don’t want to waste either your or my time arguing about it. I’m not conceding the point, just unwilling to engage in fruitless discussion.
I know that the DOM interface for the
<time>element has ways to interact with the JS Date objects. What I’m asking for is a way to get fromelement.propertiesto a Date object. If you don’t want the values themselves to be Date objects, perhaps you could have a pointer from a property to the element that defined that property.I know that iCalendar doesn’t support structured values in descriptions, but that shouldn’t prevent the HTML5 DOM from doing so. Take an example where a web page contains event data and another application wants to embed that event data in their own web pages. Rather than going through the lossy transformation to iCalendar, it could pick up the full structured description of the event. This is particularly useful for i18n if nothing else.
Thinking about validation, there are two questions to answer:
For the first case, I’d suggest that the property is ignored, as if the value wasn’t present. This is consistent with how you handle it when the
<time>element’s value isn’t in a recognised date/time syntax.For the second case, I think you are absolutely right to refer to RDFS/OWL for validation of the values when RDF is generated. Validation of the JSON would have to be through a JSON schema.
As I said, many RDF processors don’t validate the triples that they work with; you can still work with triples without it. In rdfQuery, for example, I don’t currently do any validation of the triples. I imagine that when I introduce it, I’ll ignore the invalid triple and provide a callback mechanism so that people can choose how to handle the error.
If you want to explore further applications that do validation, you could look at Jena; I’m afraid I’m not the best person to ask for assistance with it, but I’m sure #swig on irc.freenode.net will be able to help.