Re: Any limitation on attributes I can quality with "Role"?

Kevin and all,

This is a great question to pose. I myself have wondered about the use of
Role.  My personal interpretation/understanding is that Role is a stub for
more specific subtypes such as OrganizationalRole and PerformanceRole.  The
number of subtypes for Role could be extensive.  But the documentation for
Role itself doesn't provide much guidance on when to use it, or not to use
it.

The LinkRole specialization suggests that role can be applied to situations
other than people.  I imagine such applications will grow in the future.
All kinds of non-Person entities can have a role.

As Thad said, there is a balance between pioneering novel implementations
-- and having confidence that machine parsers will understand the
structured data.  My recommendation (and veterans please correct me
immediately if I'm mistaken) is to first propose a subtype of Role for a
specific application, to gain broader awareness of what you are trying to
accomplish, and then implement it.  The risk of implementing novel
interpretations that aren't tied to any documented guidance is that no one
else will be aware of what is supposed to represent.  Schema.org is a
wonderfully extensible vocabulary, but it does rely on consensus about its
meaning.

On Tue, Aug 14, 2018 at 9:58 PM, Kevin Brown <kevinbrown2354@gmail.com>
wrote:

> (sorry to send this twice to Umutcan, forgot to modify reply-to)
>
> Thank you for your response, Umutcan. It seems like wrt the entities I am
> working on (Organizations and Persons), several properties (telephone,
> faxNumber, email) are similar in content to the contactPoint property.
> contactPoint has the advantage that it can carry other forms of contact
> information - Viber usernames, ICQ handles, etc. (using the contactType
> property and probably defining an extension pointed to by Thing
> (additionalType) for the actual username or handle). But contactPoint has
> the disadvantage of ending up being denormalized (some entries for
> different email addresses, with names like "work" and "personal"; some
> entries for different phone numbers, like adding a "mobile" entry and
> storing the work number along with the work email in the same
> contactPoint).
>
> For this reason, I think I am going to go with your example to use Role as
> a qualifier or overload to each of the individual fields, unless someone
> says definitively I shouldn't do this:
>
> {
>> "@context": "http://schema.org" <http://schema.org>,
>> "@type": "Person",
>> "telephone": {
>>             "@type": "Role",
>>             "telephone": 452345345,
>>             "roleName": "mobile"
>> }
>> }
>>
>
> In thinking through different scenarios, neither way really feels correct
> to me. On one hand, I'd find it confusing (using the contactPoint approach)
> looking through contactTypes like "work", "home", "personal", and
> "KingdomOfFunGame" trying to find a particular type of contact information
> for somebody (such as their email address). On the other hand, classifying
> the contact information under the particular properties (email, telephone)
> has more of a permanent semantic sense to me; I don't expect to call the
> phone number and find it disconnected, where I would for a contactType like
> "May 2018 Scarborough Festival". Maybe overloading the accepted type for
> the email, telephone, and faxNumber properties (allowing a contactType
> instead of just Text) and identifying this change in an extension pointed
> to by additionalType would make more sense.
>
> I think using role like this is an entirely different semantic meaning to
> the word than e.g. the role of an actor in a movie, or the position of a
> player on a sports team. The actor and player are vertices on a graph, and
> Role in that context is simply additional metadata describing them. Here it
> is more like an edge connecting two Things, with additional metadata
> attached to the edge. It seems to me that that things that are most like an
> edge can be used in place of any primitive type, although the documentation
> that they can be used that way on the schema.org site is obscure,
> missing, or inferred. The Things that seem to me I can use that way are:
>
> -- primitive collection or set (though no type for this exists in
> schema.org)
> -- ItemList
> -- Enumeration
> -- Role
>
> I wonder what people think about whether I can freely substitute the last
> 3 in the list above for any primitive type value for any property?
>
> Kevin
>