Re: Schema.org External Enumerations mechanism

Reading the proposal, its goals are to (a) directly "use"
externally-maintained vocabularies and datasets, (b) encourage a common
representation for values, (c) allow decentralization, and (d) preserve
simple markup.

In the pragmatic context of schema.org there are a few things I'd look for
from an extension mechanism that had those goals:

1. When I look at http://schema.org/Person and its nationality property,
I'd like to know that some values of this property have been blessed by
schema.org, and easily see what those values are and who the official
keeper of the values is. [goals (a), (b), (c)]

*** Suggestion: For enumerated values that are in fact blessed by schema.org,
publish a link to the appropriate external URL(s) on the schema.org page
for the type (e.g. in this case http://schema.org/Country).

2. When I look at http://schema.org/LocalBusiness, I'd like to know that
some subclasses of this class have been blessed by schema.org, and easily
see what those subclasses are and who the official keeper of them is.
[goals (a), (b), (c)]

*** Question: Is this use case actually covered by this spec? "Types as
enumerations" suggests that it is, as long as the subclasses don't have new
properties, but there are no examples. The section indicates that the
expression of multiple types is difficult, but it's not clear whether that
applies to the scenarios that "we do not address here" or to the scenarios
that we do address here. :-)

*** Suggestion: If this use case is not covered in the proposal, remove the
"Types as enumerations" section and flag it as future work. If it is
covered, explain its relation to
http://schema.org/docs/extension.html(i.e. Stéphane's question).

3. I'd like to declare synonymy/sameAs between values I enumerate at
http://PigLatinCountryNames.com/ and corresponding constrained values
blessed by schema.org. [goals (b), (c), (d)] If PigLatinCountryNames.com
were able to do that, it would I think address all of Danny's concerns.

*** Suggestion: Clarify the synonymy model: e.g. whether a
http://ext.schema.org/ URL is or is not synonymous with the URL it
redirects to, and if not, what it does mean (so a site can know whether or
not to use the ext.schema.org URL).

*** Suggestion: Explicitly note that schema.org doesn't provide a sameAs
declaration today, and that any future sameAs proposal should allow one
domain to declare a constrained value to be the same as a constrained value
in another domain.

On Fri, Apr 20, 2012 at 02:13, 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
>
>