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

Re: Single heuristic mapping for property URIs

From: Dan Brickley <danbri@danbri.org>
Date: Wed, 26 Oct 2011 13:25:28 +0200
Message-ID: <CAFNgM+ZBOpdU=wzk-fxcJkHg0Y0PxMvw65h+4d_vYYvdELrwnA@mail.gmail.com>
To: Lin Clark <lin.w.clark@gmail.com>
Cc: Toby Inkster <tai@g5n.co.uk>, "public-html-data-tf@w3.org" <public-html-data-tf@w3.org>
On Wednesday, 26 October 2011, Lin Clark <lin.w.clark@gmail.com> wrote:
> This depends on authors implicitly following a particular naming
convention within their vocabularies. However, the Microdata spec is clear
that the itemtype URL is an opaque string and doesn't need to follow any
pattern. This means that someone could potentially create a Foo vocabulary
that has a Person type and a Book type.
> They could choose to have a global title property:
> http://foo.org/title
> Or they could choose to have different title properties for the Person and
the Book... this is totally OK.
> http://foo.org/Person/title
> http://foo.org/Book/title
> Or they could have something like this:
> http://vocab.org/FOO/Person
> http://vocab.org/FOO/title
> Based on the algorithm you described yesterday, property generation would
fail for the second two if I'm not mistaken.
> In addition, many content authors will probably get the case wrong, even
for vocabularies like Schema.org. If you look at the Rich Snippets testing
tool, it is clear they don't care about case because they change the
itemtype to lowercase when they display. This could very well lead authors
to believe that case is not important and thus lead to many authors using
something like http://schema.org/person for itemtypes.
> I don't think we can create a reliable URI generation method by using
case, or any other character attributes.

In rdf I do urge people to stick to case conventions when they're using
Latin-based scripts. But it would be inappropriate for W3C to impose a
choice of script worldwide. Not every writing system has a comparable notion
of 'case'...

Received on Wednesday, 26 October 2011 11:26:04 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 20:08:25 UTC