Re: Schema.org External Enumerations mechanism

Good to see a nice heated discussion :)

There is nothing stopping anyone today from using wikipedia urls as
identifiers for countries or whatever else, just as there is nothing
stopping anyone from using any vocabulary they choose.

The goal of schema.org (as Dulitz points out) is to provide a single place
(for the kind of webmaster who doesn't read this group for fun) to get as
much of the vocabulary they need as schema.org can possibly provide. Which
is why we want to 'bless' certain external vocabularies as being recognized
by us.

We can do this by saying on say the http://schema.org/Country page that
http://en.wikipedia.org/Country lists the canonical list of countries and
let the webmaster deal with the rest or have schema.org urls for each of
the countries and have the schema.org pages point to the corresponding
wikipedia pages. This is no more an attack on the decentralized nature of
the web than are url shorteners.

And of course, people are absolutely free to use wikipedia or whatever
other urls directly.

guha

On Fri, Apr 20, 2012 at 2:13 AM, Danny Ayers <danny.ayers@gmail.com> wrote:

> On 19 April 2012 20:30, Dan Brickley <danbri@danbri.org> wrote:
>
> [snip]
>
> I'm really not sure there's any net benefit over using the original
> URIs. Ok, there's conflict between the identification of a thing and
> that of a document about the thing. Having schema.org "bless" a given
> vocabulary is arguably a good thing, but the minting of new URIs for
> the vocabularies seems redundant. HTML authors *are* used to pointing
> to e.g. Wikipedia for definitions, what is to be gained from
> centralizing things further?
>
> There are at least two approaches that will achieve the same ends
> without compromising the distributed nature of the Web -
>
> 1. refer to a target page directly, tweak property definition
>
> so instead of:
>  <link itemprop="nationality"
> href="http://ext.schema.org/wikipedia/en/United_States"/>
> we'd have:
>  <link itemprop="nationality"
> href="http://en.wikipedia.org/wiki/United_States" />
>
> I can't actually see a definition of "nationality", but the conflict
> mentioned above would be avoided if it were defined as being "a page
> describing the nationality".
>
> 2. refer to a target resource directly
>
>  <link itemprop="nationality"
> href="http://dbpedia.org/resource/United_States" />
>
> It could be argued that perhaps dbPedia isn't likely to be as stable a
> reference as Wikipedia. But nothing can be considered rock solid for
> perpetuity, we just have to trust in Cool URIs. The argument about
> "correct and currently fashionable standard" isn't very compelling, in
> fact there's quite a strong counter-argument: if person uses the
> definition from Wikipedia today, should it be schema.org's decision
> tomorrow that what they /really/ mean is the definition from
> Encyclopedia Universalis?
>
> As for the "regular markup" argument, the target systems already use
> regular markup, and the URIs appear to be shorter. Perhaps a more
> significant angle is: how does someone find a suitable URI for e.g.
> "Linear Algebras" by Gilbert Strang? If we're deferring to the Library
> of Congress for definition, then it'd be appropriate to go and search
> over there - and the result is given *in their naming scheme*, it
> needs modifying to get it into schema.org's. That's more friction, not
> less.
>
> Even with my architecture astronaut's helmet on I reckon the basic
> approach of schema.org is an experiment worth trying, relaxing a
> constraint of the traditional semweb approach to encourage more
> publication of data (well, "constraint" is a bit strong for the idea
> that vocabularies should be distributed, nothing's ever ruled out
> having biggish centralized vocabs). Whatever, pragmatism trumps holy
> cows. But the use of schema.org URIs for terms from collections like
> Wikipedia doesn't really seem to offer any significant concrete
> benefit in return for it's compromise.
>
> Cheers,
> Danny.
>
> --
> http://dannyayers.com
>
> http://webbeep.it  - text to tones and back again
>
>