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

Re: URIs for properties at schema.org

From: Bob Ferris <zazi@smiy.org>
Date: Sat, 15 Oct 2011 11:44:50 +0200
Message-ID: <4E995612.3040508@smiy.org>
To: public-vocabs@w3.org

On 10/15/2011 1:11 AM, Gregg Kellogg wrote:
> On Oct 14, 2011, at 3:32 PM, John Panzer <jpanzer@google.com
> <mailto: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.

Following these examples of microdata, I really don't understand why 
there are such problems with the utilisation of prefixes and CURIEs, 
which I personally find a bit clearer and easier extensible and mixable 
than this kind of "wanna be" (not so intuitive) prefix approach.
In object-oriented programming languages we usually intuitively work 
with package names and shortcut (prefix) mechanisms (รก la import 
statements at the beginning of a class definition). I don't really 
understand why there are such big problems of applying this mechanism to 
knowledge representation as well (as it is already done with the 
prefixing mechanism in RDFa, RDF/XML, Turtle/N3 and SPARQL).



PS: I guess this is more a topic for the microdata mailing list ;)
Received on Saturday, 15 October 2011 09:45:35 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:29:21 UTC