W3C home > Mailing lists > Public > public-vocabs@w3.org > September 2014

Re: September Update on Sports

From: Dan Brickley <danbri@google.com>
Date: Thu, 25 Sep 2014 14:16:13 +0100
Message-ID: <CAK-qy=5FfS7eUGcT0sZ+JsjiQfYRnrVGzE1JR7W1YjOMy57LiA@mail.gmail.com>
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

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:29:44 UTC