W3C home > Mailing lists > Public > public-vocabs@w3.org > November 2011

RE: draft JobPosting addition for Schema.org

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>
Message-ID: <00f201cca006$16e90680$44bb1380$@com>
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.
> doesn't ascribe meaning to property names, but leaves that to

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.

Received on Friday, 11 November 2011 00:09:23 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:48:43 UTC