- From: Dan Brickley <danbri@google.com>
- Date: Thu, 25 Sep 2014 12:15:40 +0100
- To: Dan Scott <dan@coffeecode.net>
- Cc: Vicki Tardif Holland <vtardif@google.com>, "Jason Johnson (BING)" <jasjoh@microsoft.com>, SchemaDot Org <public-vocabs@w3.org>, Gregg Kellogg <gregg@greggkellogg.net>
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 ... 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... Dan
Received on Thursday, 25 September 2014 11:16:11 UTC