- From: Jim Rhyne <jrhyne@thematix.com>
- Date: Thu, 10 Nov 2011 16:08:48 -0800
- To: "'Gregg Kellogg'" <gregg@kellogg-assoc.com>
- Cc: <public-vocabs@w3.org>
On Nov 8, 2011 at 10:56 PM Gregg Kellogg wrote: > If you look in the Microdata spec [1], you'll see examples of this usage. Microdata > doesn't ascribe meaning to property names, but leaves that to vocabularies. I found this in the spec shortly after posting the note. I also followed the public email trail about RDF and Microdata and HTML5. I now think that this issue resolves to the vocabulary specification mechanism (of which there is none that is standardized - but that need not stop us from considering the issue of how to tell a processor what sense to make of a set of microdata items). The vocabulary could assert that there is an intended class for the untyped @itemscope, and it could also assert the @itemprop names that are legal. OTOH, there can be situations in which there are certain legal combinations of @itemprop names, and creating classes in the vocabulary just to handle these constraints may not be justified. That thinking led me to the notion of "constraint patterns" in a vocabulary specification. Here's a prose example: "Properties A and C may be used together, or properties B and C may be used together, but properties A and B are exclusive and may not be used together. The combination of A and C means blah-blah and the combination of B and C means yah-yah" One case I am currently looking at is structured prices for rental items, where the price is possibly a (duration, price) pair or a (datetime, duration, price) triple. These are sufficiently common IMO to warrant introducing a StructuredValue subclass e.g. RentalPrice. Jim
Received on Friday, 11 November 2011 00:09:23 UTC