Re: September Update on Sports

On Sep 25, 2014 7:15 AM, "Dan Brickley" <danbri@google.com> wrote:
>
> On 25 September 2014 12:05, Dan Scott <dan@coffeecode.net> wrote:
> >
> > On Sep 24, 2014 11:00 AM, "Vicki Tardif Holland" <vtardif@google.com>
wrote:
> >>
> >>
> >> On Tue, Sep 23, 2014 at 3:47 PM, Gregg Kellogg <gregg@greggkellogg.net>
> >> wrote:
> >>>
> >>>
> >>> It would also make sense to have numberedPosition have a domain of
> >>> SportsRole, and not OrganizationRole.
> >>>
> >>> Alternatively, make something like "position" more abstract, and add
to
> >>> OrganizationRole.
> >>
> >>
> >> The proposal contains a "namedPosition" property on OrganizationRole.
Does
> >> that meet your needs?
> >
> > Wait... Why add a namedPosition property when http://schema.org/name
should
> > work just fine? It is, after all, the name of the role being played
(whether
> > in an organization, sport, or other context).
>
> (draft at) http://sdopending.appspot.com/namedPosition

Yes, I read the draft. Wouldn't respond if I wasn't informed.

> ... this allows URL, which might be from some more specialised
> sporting standards, or from generic large datasets like
> Wikipedia/Wikidata/DBpedia/Freebase.
>
> e.g. http://www.wikidata.org/wiki/Q622747  "position in gridiron football"
> instance of  http://www.wikidata.org/wiki/Q694589 "American football
> position" (which has Freebase IDs etc)
>
> Whereas URLs as values for 'name' aren't generally encouraged...

Hmm. It seems weird that schema.org will accept Text in place of any other
more specific range, but doesn't accept a more specific URL in place of
Text.

If you really want to go down this route, though, I would suggest roleName
directly on Role that could serve for any future subtypes as well.
Otherwise, properties like characterName and namedPosition are just going
to propagate as more Role subtypes emerge for different contexts.