- From: Nathan <nathan@webr3.org>
- Date: Sun, 19 Jun 2011 16:17:11 +0100
- To: Alan Ruttenberg <alanruttenberg@gmail.com>
- CC: www-tag@w3.org, "Henry S. Thompson" <ht@inf.ed.ac.uk>, Jeni Tennison <jeni@jenitennison.com>, Manu Sporny <msporny@digitalbazaar.com>
Alan Ruttenberg wrote: > On Sat, Jun 18, 2011 at 6:44 PM, Nathan <nathan@webr3.org> wrote: > >> Henry S. Thompson wrote: >> >>> ISSUE-35 -- Microdata/RDFa relationship >>> >> Nice to see this being focussed on. >> >> I have some concerns that the major background difference between the >> approaches, which resulted in two differing specifications, has not been >> given much focus. From Jeni's document: >> >> * RDFa allows entities to be assigned more than one type; microdata >> supports a maximum of one type >> > > Microdata's type hierarchy includes multiple inheritance. So (if) you had > the power to define a new type, you could have it have the multiple types > you desire as parents and then use that single type, with the same effective > result as using multiple types directly. > > It is a bigger deal, IMO, that there is a gatekeeper (schema.org) for > defining new types. > > The non-monotonicity resulting from schema.org defining as Text many > properties that will be in the future candidate for being Things is also a > major difference. Agree, however with the note that it's focussed on Class based inheritance rather than property based (or both together). Best, Nathan > Alan > > >> I firmly believe this is the key difference in approaches, microdata is >> primarily focused on using a classical "class blueprint" style of schema, >> where each class/type is set in stone, and has a fixed enumerable set of >> properties. Whereas RDF(a) mixes and matches from multiple vocabularies. >> >> Whilst this only results in minor difference in the surface syntax, the >> mental model, processing model, and how the data is generated / consumed / >> interacted with and consumed is very different. >> >> My primary concern is that this may need to be addressed first of all, >> because if the different approaches are both needed, then two different >> surface syntaxes for the two styles may well be needed, and the possible TF >> may need to focus on clearly identifying the needs of both approaches to >> ensure that features from one don't creep in to the other making it >> unusable. If it isn't addressed, then the differences in background mental / >> schema models may be enough to make a merged single syntax useless/confusing >> for one or more parties. >> >> >> TBL: The Task Force may fail -- but I don't want them to come back and >>> say "We succeeded -- no change is necessary" >>> >> +1, Can't stress that enough. >> >> Best, >> >> Nathan >> >> >
Received on Sunday, 19 June 2011 15:18:22 UTC