Roles as substitutes for object/datatype properties

[Aqua1ung]

Attempt to summarize and develop some ideas on Roles we discussed a couple of weeks ago during an OBI meeting:

The current OBI modeling paradigm makes extensive use of roles. Transitioning from an ontology as a mere controlled vocabulary to an ontology of triples (...other than rdf:type and rdfs:subClassOf) requires increased focus on object and datatype properties. Attempting to make up for the dearth of object/datatype properties by cooking up more and more roles might not achieve its goals, as can be seen from the following example:

One way of saying that Jane is Sally's daughter could easily be achieved by employing a specific object property such as "hasMother" or the like:

Jane hasMother Sally (or Sally hasDaughter Jane etc.)

Within OBI circles there is, however, a feeling that the same can be achieved by employing a less specific object property such as hasRelative, accompanied by a hasRole statement:

Jane hasRelative Sally and Sally hasRole MotherRole.

It should be obvious, however, that this conjunction could very well be satisfied by Jane's being Sally's niece and Carol's cousin, where Carol is Sally's daughter.

My opinion is thus that, in its present (incomplete) guise, the role "mechanism" cannot function as a substitute for more specific object and/or datatype properties--and the audience seemed to have concurred with this conclusion. The recommendation that has emerged from the meeting is that OBI devs. should be more open to the addition of object and datatype properties: enriching OBI with properties deserves OBI developers' attention and focus just as much as taxonomy work does. Relying on RO to fill this gap might not be the best policy at this point.

[Aqua1ung]

Despite the previous call for not regarding Roles as substitutes for object/datatype properties, Roles might not be going anywhere anytime soon. As someone (Damion? Gully?) noticed during the meeting, while whipping up object/datatype properties might work well for cases in which roles are permanent (such as hasMother, hasFather etc.), or where time does not matter, appeal to roles may be the best way to model situations in which roles are time sensitive, such as "Mark was the CEO of Earache Records between May 1st 2005 and June 23 2015" and the like. In order to capture such situations, a bunch of other object and datatype properties are required to enhance the Role "mechanism." Here below I am making a suggestion, though certainly it is not the only possibility to make Roles work as intended:

1. add two datatype properties has(Role)Start and has(Role)End, both from Role (obo:BFO_0000023) to xsd:dateTime;
2. add one object property withRespectTo from Role (obo:BFO_0000023) to, say, Entity (obo:BFO_0000001).

With these, the situation described above can be captured as the following sequence of triples:

Mark hasRole ER_CEORole ER_CEORole rdf:type obo:BFO_0000023 ER_CEORole withRespectTo EaracheRecords ER_CEORole has(Role)Start 2005-05-01T00:00:00 ER_CEORole has(Role)End 2015-06-23T23:59:59

To this one might add a few triples about EaracheRecords, such as EaracheRecords rdf:type RecordCompany etc.

[Public-Health-Bioinformatics]

About "Jane hasRelative Sally and Sally hasRole MotherRole", so there is no logical expressivity to state a constraint on Sally (that she is a Mother) with respect to the aforementioned HasRelative instance. Seems this is a case where the logical expressivity in our natural language reference power is not going to happen in the near future with OWL; but anyone know of some expressive languages and reasoners that can handle this?

"withRespectTo" seems necessary. A generic hasStart , hasEnd should work esp if domain is "role"!

My notes on role: I see two kinds of "role" that may have different requirements: biological/functional and sociological. A functional role seems to be a nickname for describing a set of functionality that can be activated in the role holder. A person can provide a functional "doctor" role if they have learned the medical diagnostic and therapeutic services associated with (or defined by) the doctor profession. They'll do if someone yells "Is there a doctor in the house!". Here I think it would be sufficient to say a functional doctor is someone who can provide services or functions X,Y,Z. I've been drawn to (noun) "X 'has capability' some Y, e.g. "General Practitioner: subClassOf doctor and 'has capability' common disease diagnosis". A process could reference inputs that have certain capabilities directly rather than referencing inputs "bearing" certain roles. A functional role is a conventional name for an entity capable of delivering a set of functionality. I suspect a separate "role" hierarchy does NOT need to exist in this case to organize such classes of entity.

The sociological role may reference some inherent functionality of an entity, but beyond that it literally or informally involves social contracts. The college of physicians and surgeons may decree that Jones is a doctor; that entitlement is one step removed from the functional knowledge Jones has about providing doctor services. Jones might even be associated with malpractice.

So the use of "role" spans functionality that seems more inherent - timeless - in an organism, to sociological uses that are time conditional, and requiring relations with contractual parties, as your second ER_CEORole example points to. But even functional ones can be time and context conditional, e.g. puberty and menopause.

[Aqua1ung]

A 3-place ("ternary") object property such as "Sally hasRole MotherRole vis-a-vis Jane" would actually be what we need here, though unfortunately there's no way anything like that would "pass" a decidability "test" :-) . Description Logics, and OWL-DL, were obviously designed with decidability in mind, so we'll have to make do with binary relations/properties, which is why we have to make recourse to wacky entities such as "roles" and the like. Some people (mostly computer scientists) call the "technique" of treating abstract entities (such as roles) on the same ontological par with regular substantial entities/individuals reification, but I'd caution against the use of the word "reification" in this conjuncture.

As for telling "role" apart from "function," there have been discussions in this respect, going back at least 10 yrs., and yes, to my recollection, the opinion that has emerged sort of half-mouthedly was that role mostly covers what you've described as "sociological role." At any rate, what I recall is that something has a function even if it never fulfills that function (such as "heart has function blood pumping function" for a heart that has been grown in the lab from stem cells, say), while role depends on actually fulfilling it. At any rate, coining object properties such as hasMother is an attempt at bypassing this morass of issues which I, for one, am not very eager to go into--at least not at this point in time. My guess is that we're likely to encounter in our daily OBI-developing life mostly instances of "roles" that are not time-sensitive, hence going the object property route (as opposed to the "role" route) might be all we need. Bottom line is, let's get started on churning out them object and datatype properties!

[jamesaoverton]

This was an interesting discussion, but we have no plans to act on it at the current time.