W3C home > Mailing lists > Public > www-tag@w3.org > June 2011

Re: Draft minutes for TAG telcon of 2011-06-16

From: Alan Ruttenberg <alanruttenberg@gmail.com>
Date: Sun, 19 Jun 2011 01:03:40 -0400
Message-ID: <BANLkTimz09oO9piDgc8Xu+7=ZeSjrWf1_g@mail.gmail.com>
To: nathan@webr3.org
Cc: www-tag@w3.org, "Henry S. Thompson" <ht@inf.ed.ac.uk>, Jeni Tennison <jeni@jenitennison.com>, Manu Sporny <msporny@digitalbazaar.com>
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.


> 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 05:04:28 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:56:39 UTC