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

I wrote this post some while back "The role of Role in Schema.org
<https://dataliberate.com/2015/04/15/the-role-of-role-in-schema-org/>"

Maybe it will help in understanding its usage.

~Richard.

Richard Wallis
Founder, Data Liberate
http://dataliberate.com
Linkedin: http://www.linkedin.com/in/richardwallis
Twitter: @rjw

On 15 August 2018 at 14:36, Michael Andrews <nextcontent01@gmail.com> wrote:

> 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
>>
>
>