Re: Schema.org External Enumerations mechanism

Hi Guha,

I try to reconcile the various requirements here (yeah, I know, this is my job:-). 

So... let me take up your comparison with url shorteners. The question is: what is returned if I do a GET on 

http://ext.schema.org/wikipedia/en/United_States

surely it should not be 404:-)

There are multiple things that could be done, which may be helpful. Eg, if content negotiations is used, and the request is for an HTML page, one could imagine this is redirected to the wikipedia page. If the content negotiation leads to some RDF serialization, I could imagine that this would return a small RDF, saying something like

<http://ext.schema.org/wikipedia/en/United_States> owl:sameAs
  <http://dpbedia.org/resource/United_States> .

(Actually, you may also add a bunch of other sameAs here, eg, referring to the corresponding freebase entries.)

Your core constituency, ie, the webmasters, would use the ext.schema URI-s; linked data people could use the same but a follow-your-nose would then lead to others, commonly used URI-s.

Actually, this could be used for http://schema.org/Person, for example, if we want to declare them as the same as foaf:Person.

Of course, this requires some setup on the server side, which should know about the various URI schemes. But I do not think it is a major deal.

Just an idea...

Ivan






On Apr 22, 2012, at 03:26 , Guha wrote:

> 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
> 
> 


----
Ivan Herman, W3C Semantic Web Activity Lead
Home: http://www.w3.org/People/Ivan/
mobile: +31-641044153
FOAF: http://www.ivan-herman.net/foaf.rdf