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

Kevin,

Role is only somewhat understand by parsers in the wild and Search engines,
but you are welcome to use it.  However, what is more widely understood for
your particular case, and what you probably missed, is the
following...ContactPoint

{
    "@context": "http://schema.org",
    "@type": "Person",
    "name": "Thad Guidry",
    "contactPoint": [{
        "@type": "ContactPoint",
        "telephone": "+1-555-555-1234",
        "contactType": "mobile"
    }]
}


On Tue, Aug 14, 2018 at 9:36 AM Umutcan Simsek <umutcan.simsek@sti2.at>
wrote:

> Hi Kevin,
>
> Giving my best to answer your questions below:
>
> On 08/14/18 15:56, Kevin Brown wrote:
>
> I understand the RoleName attribute of Role superseded NamedPosition, and
> the example attributes to qualify with Role on the schema.org/Role page
> ('member', 'actor') indicate Role being used in the context of the
> relationship between a natural person and a thing.
>
> There is a pending extension which adds Role to the subjectOf attribute of
> Thing. This would widen the context of Role to the relationship between any
> arbitrary thing and any other thing, if I am understanding the proposed
> usage correctly. The pending extension subtype linkRole expands the context
> to  web links between arbitrary things.
>
> Can I use Role to quality any attribute of any thing I wish, similar to
> how I can arbitrarily use a collection of entities anywhere the Schema.org
> indicates a single entity is accepted as a value? My particular use case
> involves the "telephone" attribute of Person and Organization. I need to
> markup multiple telephone numbers for one person, for example, with
> identifiers like "default", "mobile", "home", etc.
>
> Regarding the use of Role: Although all the examples are with object
> properties, I **think** there is nothing against a usage like this:
> {
> "@context": "http://schema.org" <http://schema.org>,
> "@type": "Person",
> "telephone": {
>             "@type": "Role",
>             "telephone": 452345345,
>             "roleName": "mobile"
> }
> }
>
> However for your particular use case, an alternative and maybe a more
> straightforward approach would be using the ContactPoint type with as it
> can be used on Person and Organization with the contactPoint property. This
> type has a contactType property where you can specify the type of a
> telephone number as 'mobile'.
>
>
> The telephone entity seems to be a primitive type, expecting a text value;
> even though the Schema.org page shows it in the hierarchy like "Thing >
> Property > telephone", the https://schema.org/telephone page does not
> show it as inheriting attributes from Property. If it did inherit from
> Property I'd probably (naively maybe) think "identifier" from Thing might
> be the best to use for the type of telephone. But as I understand (maybe my
> developer's mindset), primitive types don't inherit from Thing, and the
> telephone page seems to indicate that.
>
> telephone is a property, not a type. In schema.org properties do not have
> properties.  Text would be, for instance, a primitive type.
>
>
> So I'm considering qualifying the "text" primitive value of "telephone"
> with role to identify "mobile", etc., if I'm free to use Role on any
> arbitrary attribute. Is that the case? And can anyone help me with maybe
> more of the general principles involved (and intended direction of context
> for Role) also?
>
> I've worked as a developer for about 15 years. Writing my first BSD kernel
> driver and feeling like I had a grasp of kernel architecture was easier
> than gaining some feeling of competency in the semantic web area. I've read
> all of the semantic web books I could find and understand OWL, SPARQL, etc.
> to some level. I've had difficult finding any good entry-level resources
> for on-ramping developers. I hope to write some once I feel like I really
> have a grasp of the domain.
>
> Thank you,
>
> Kevin
>
> ______________________________________________________________________
> This email has been scanned by the Symantec Email Security.cloud service.
> For more information please visit http://www.symanteccloud.com
> ______________________________________________________________________
>
>
> --

Thad
+ThadGuidry <https://plus.google.com/+ThadGuidry>