Re: URIs for properties at schema.org

(Appologies if this shows up twice, the first from a separate account seems to have gone to a filter).

Note that the just-released Microdata to RDF draft defines property URI generation using the same domain as the @itemtype, not relative to the type itself. Read about it at [1]; comments welcome, feedback to public-html-data-tf@w3.org<mailto:public-html-data-tf@w3.org>.

Gregg

[1] http://lists.w3.org/Archives/Public/public-html-data-tf/2011Oct/0066.html

On Oct 12, 2011, at 3:57 PM, Martin Hepp wrote:

FYI: GoodRelations will clearly define in its next service update that the URIs of properties should be formed by attaching the local name of the property to the base URI of the vocabulary, not to the URI of the itemtype that gives the context.

I also think that this is the most useful pattern for most cases, but if that cannot be written in the standard, Microdata parsers must simply offer this as a heuristic.


On Oct 12, 2011, at 10:44 AM, Bob Ferris wrote:

Hi,

On 10/12/2011 9:45 AM, Bernard Vatant wrote:
Thanks for the pointer to any23.org<http://any23.org> <http://any23.org>

An issue I clearly see with URIs such as http://schema.org/Person/name
is that some properties are used by more than one class. So we'll have
for example http://schema.org/Movie/duration and
http://schema.org/Event/duration potentially misleading to the idea that
they are different properties with specific domains, although the
definition found for "duration" is exactly the same at both
http://schema.org/Movie and http://schema.org/Event : "The duration of
the item (movie, audio recording, event, etc.) in ISO 8601 date format
<http://en.wikipedia.org/wiki/ISO_8601>." So it's another argument for
having this definition clearly published at a single place, under
http://schema.org/duration - with expected range
http://www.schema.org/Duration. (which BTW would lead to the side issue
of having a property and its range just differing by one character case,
not a good practice in my opinion).

+1 for excluding the class domains in the URIs of multiple classes spanning properties, i.e., a name is a name is a name. A human user and also a machine will get the relation (specific meaning) of name via its context, i.e., the types of that resource, e.g., schemaorg:Person => a person's name etc.

Cheers,


Bo


PS: otherwise we would probably end up with something the like the Freebase vocabulary ;)