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

Re: URIs for properties at schema.org

From: Gregg Kellogg <greggkellogg@gmail.com>
Date: Fri, 14 Oct 2011 16:11:18 -0700
Message-Id: <6DD62F37-7AD4-4B43-9BEB-1F3A26478AD2@gmail.com>
Cc: Bob Ferris <zazi@smiy.org>, "public-vocabs@w3.org" <public-vocabs@w3.org>
To: John Panzer <jpanzer@google.com>
On Oct 14, 2011, at 3:32 PM, John Panzer <jpanzer@google.com> wrote:

> Thanks; with regard to this, I wasn't sure what "@itemprop names which are not absolute URIs are resolved as relative URIs either to @itemtype or Document base." means. 

Basically, if an @itemprop is a bare name, and not an absolute URI, it is added to the
@itemtype URI using the described mechanism. If there is no @itemtype, it uses the document base and is added to it using the appropriate algorithm for resolving relative URIs.

For example, if @itemprop="name" and @itemtype="http://schema.org/Person" the resulting URI would be http://schema.org/name.

If there is no @itemtype, better to generate something rather than nothing. So, if base were http://example.com/foo, @itemprop would resolve to http://example.com/name.

Of course @itemprop could be something other than a bare name, such as "foo/bar" and the same rules apply.

Gregg
> --
> John Panzer / Google
> jpanzer@google.com / abstractioneer.org / @jpanzer
> 
> 
> 
> On Wed, Oct 12, 2011 at 12:40 PM, Gregg Kellogg <greggkellogg@gmail.com> wrote:
> 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.
> 
> Gregg
> 
> [1] http://lists.w3.org/Archives/Public/public-html-data-tf/2011Oct/0066.html
> 
> On Oct 12, 2011, at 1: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>
> >>
> >> 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 ;)
> >
> >
> 
> 
> 
> 
Received on Friday, 14 October 2011 23:12:07 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 22 May 2012 06:48:56 GMT