W3C home > Mailing lists > Public > public-html-data-tf@w3.org > October 2011

Re: Multiple itemtypes in microdata

From: Ivan Herman <ivan@w3.org>
Date: Thu, 20 Oct 2011 10:22:43 +0200
Cc: Ian Hickson <ian@hixie.ch>, Bradley Allen <bradley.p.allen@gmail.com>, Stéphane Corlosquet <scorlosquet@gmail.com>, "public-html-data-tf@w3.org" <public-html-data-tf@w3.org>
Message-Id: <084442D0-118C-41F0-8F65-17A205358E64@w3.org>
To: Gregg Kellogg <gregg@kellogg-assoc.com>

On Oct 20, 2011, at 04:03 , Gregg Kellogg wrote:

[snip]
>> 
>> But even with that, actually, the schema.org vocabulary is inadequately 
>> defined. It doesn't have what I would call a specification. For example, 
>> there's no conformance section defining the conformance classes. Or to 
>> pick a random property: there's no rules saying that "wordCount" can't be 
>> negative, and there's no conformance requirements on processors saying 
>> what they should do if "wordCount" _is_ negative.
> 
> It's certainly evolving. I was presuming the schema.rdfs.org version, which is referenced from schema.org [1]. Even this could be defined more tightly, as you suggest. The point is, that an OWL/RDFS based vocabulary can specify these things unambiguously.

As an aside: the schema.rdfs.org is now superseded by the official schema.org version:

http://schema.org/docs/schemaorg.owl

> 
>>> [...]
>>> 
>>>> Any software that handled the above in equivalent ways (e.g. finding a 
>>>> vCard with a name "Jill Darpa" in the second case) would be 
>>>> non-conforming implementations of the vCard microdata vocabulary.
>>> 
>>> It could just mean that the vCard HTML vocabulary isn't compatible with 
>>> the Microdata to RDF definition, in that case.
>> 
>> This isn't something specific to vCard. These two items:
>> 
>>  <p itemscope itemtype="data:,a#"><b itemprop=b>x</b></p>
>>  <p itemscope itemtype="data:,a#"><b itemprop="data:,a#b">x</b></p>
>> 
>> ...state two different things, and treating them as equivalent would not 
>> be conforming within a microdata context.
> 
> Well, this is really the crux of the matter. If the TF adopts a URI generation scheme that is incompatible with the HTML Microdata spec, we risk a formal objection disallowing such a specification from being published as a recommendation. If we basically duplicate the original predicate URI generation algorithm, we ignore the needs of RDF vocabularies, and recommend that all property names be specified as full URIs, or that Microdata is not recommended as a means of representing data in these vocabularies. By ensuring that RDFa and Microdata can coexist in the same document (albeit with duplicate properties), this may be the best recommendation.
> 


I think we can be more 'lax' than that. We have to agree and document that the microdata->RDF mapping is, in some way, "lossy", insofar as it would map the two properties listed by Hixie to the same property. In practice I do not see that as a major problem for those who use the RDF mapping results; for most of the vocabularies around, like the ones defined originally for RDF or for Schema.org (which defines the property URI-s in the OWL file referred above in a way that works perfectly ok with the current mapping) this mapping will be all right. Separately, the editorial 'advice' or whatever should be that if using a vocabulary in a microdata setting, and @itemtype is used, the the @itemprop values should not use absolute URI-s for the properties that belong to the vocabulary defined by the @itemtype. We could also choose to be one step more strict and disallow (or at least raise a warning) when the author does that.

To be honest, I do not see where this would really create problems in an RDF setting.

Ivan 



----
Ivan Herman, W3C Semantic Web Activity Lead
Home: http://www.w3.org/People/Ivan/
mobile: +31-641044153
PGP Key: http://www.ivan-herman.net/pgpkey.html
FOAF: http://www.ivan-herman.net/foaf.rdf







Received on Thursday, 20 October 2011 08:21:17 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Thursday, 20 October 2011 08:21:19 GMT