- From: Dan Brickley <danbri@google.com>
- Date: Thu, 25 Sep 2014 14:16:13 +0100
- To: Dan Scott <dan@coffeecode.net>
- Cc: "Jason Johnson (BING)" <jasjoh@microsoft.com>, Gregg Kellogg <gregg@greggkellogg.net>, SchemaDot Org <public-vocabs@w3.org>, Vicki Tardif Holland <vtardif@google.com>
On 25 September 2014 13:08, Dan Scott <dan@coffeecode.net> wrote: > > 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. Didn't mean to suggest otherwise! Just there are various earlier notes, PDFs etc floating around so I thought another URL wouldn't hurt. >> ... 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. There comes a point where flexibility becomes chaos. Having URLs randomly in all the text-oriented fields I think crosses that line. But maybe that's just an unanalyzed intuition. > 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. roleName on Role (expecting Text or URL) works for me, Dan
Received on Thursday, 25 September 2014 13:16:51 UTC