On Monday, October 13, 2014, Markus Lanthaler <markus.lanthaler@gmx.net> wrote: > On Thursday, October 09, 2014 9:46 PM, Dan Scott wrote: > > On Thu, Sep 25, 2014 at 9:24 AM, Vicki Tardif Holland < > vtardif@google.com <javascript:;>> wrote: > >> On Thu, Sep 25, 2014 at 9:16 AM, Dan Brickley <danbri@google.com > <javascript:;>> wrote: > >> >> 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, > >> > >> Promoting "namedPosition" to Role and renaming the property "roleName" > >> or the like soungs good to me. > > > > Thanks for the positive response, Vicki! I've opened > > https://github.com/rvguha/schemaorg/pull/146 in the hopes of making > > this (or the like) happen. > > Maybe I missed something but why don't we simply use "name" with "Role" to > give a role a name? Is name used for something else with roles? > > roleName has both URL and Text in its range, while name has just Text. IMO, identifying the type of a role using a URI rather than a string should be encouraged. We may describe two roles of "forward", but the position is differ by in, as Basketball and Football/Soccer. Personally, I'd rather see an object-ranged property that can fallback to Text using schema.org's content model. Gregg -- > Markus Lanthaler > @markuslanthaler > >
Received on Monday, 13 October 2014 17:10:50 UTC