Add class for ComplexRelationship

[uscholdm]

We have this at two of our clients. It looks like this:

gist:ComplexRelationship
	a owl:Class ;
	rdfs:subClassOf [
		a owl:Restriction ;
		owl:onProperty gist:connectedTo ;
		owl:minCardinality "2"^^xsd:nonNegativeInteger ;
	] ;
	skos:definition "A reified relationship between two or more individuals. In the case where the relationship instantiates a binary relationship between a subject and an object, the the two individuals are linked to the complex relationship using the properties hasRelSubject and hasRelObject, respectively."^^xsd:string ;
	skos:editorialNote "If this gets folded into gist, then it will be a superclass of gist:TemporalRelation"^^xsd:string ;
	skos:prefLabel "Complex Relationship"^^xsd:string ;
	skos:scopeNote
		"Two main uses of this class are 1) to represent N-ary relations and 2) to attach additional information about a link between two individuals. This class is used to work around OWL being limited to binary properties."^^xsd:string ,
		"Use the annotation, gist:reifiesProperty to indicate which property is being reified."^^xsd:string
		;
	.

gist:hasRelObject
	a owl:ObjectProperty ;
	rdfs:subPropertyOf gist:connectedTo ;
	rdfs:domain gist:ComplexRelationship ;
	skos:definition "Relates a binary ComplexRelationship to the object of the relationship."^^xsd:string ;
	skos:prefLabel "has relationship object"^^xsd:string ;
	.

gist:hasRelSubject
	a owl:ObjectProperty ;
	rdfs:subPropertyOf gist:connectedTo ;
	rdfs:domain gist:ComplexRelationship ;
	skos:definition "Relates a binary ComplexRelationship to the subject of the relationship."^^xsd:string ;
	skos:prefLabel "has relationship subject"^^xsd:string ;
	.

gist:reifiesProperty
	a owl:AnnotationProperty ;
	rdfs:range xsd:anyURI ;
	skos:definition "Relates a ComplexRelationship to the property being reified."^^xsd:string ;
	skos:prefLabel "reifies property"^^xsd:string ;
	skos:scopeNote "Domain includes gist:ComplexRelationship"^^xsd:string ;
	.

[rjyounes]

From the point of view of conceptual organization, I like the idea of a superclass of TemporalRelation that may not be time-delimited.

However, I don't like the properties because they're misleading. A hypothetical class Employment logically "reifies" both hasEmployer and hasEmployee, but it's arbitrary and misleading to assert that it reifies one or the other of these. You can't say it reifies both if you're going to use hasRelSubject and hasRelObject since you can't untangle which belongs to which. Though I suppose you could say it reifies both, and not make the hasRelSubject and hasRelObject assertions.

I might not have defined either hasEmployer and hasEmployee, in which case it reifies nothing. And in that case, the superclass doesn't buy you anything because it has no semantics.

[uscholdm]

I thought we have been through this already, perhaps it was via email.

Employment logically "reifies" both hasEmployer and hasEmployee

Whatever gave you the idea that Employment could reify both a property and its inverse? It could reify either. To reify both would be perverse. Which is reified is determined by hasRelSubject and hasRelObject.

I might not have defined either hasEmployer and hasEmployee, in which case it reifies nothing.

TemporalRelation is a relationship holding for a period of time. It may or may not be useful to explicitly create the property. That does not change the meaning of TemporalRelation. It is still a relationship holding for a period of time. That relationship is still being reified.

[rjyounes]

We have been through this already, via email, but I didn't buy it. I don't know what you mean by "to reify both is perverse." Logically, Employment is bidirectional (I.e., encompasses the relation of employer to employee and the inverse). To have to say which relationship it reifies is perverse, IMO.

To your second point: TemporalRelation provides the semantics of a start and end date. If you reject the properties for the reasons I give above, then ComplexRelationship has no semantics (beyond that there are at least two connected things) so it doesn't buy you much semantically to subclass it.

[uscholdm]

Perhaps we can bring this up in a gist issues session. We use ComplexRelationship at Platts. Dan uses it at MorganStanley. I prefer not to have to keep recreating it for each client project - hence putting it in gist. You are not required to use it.

[DanCarey404]

I am no longer in love with the generic properties to use with :ComplexRelation. At the time MarkW and I came up with them, it seemed a good way to prevent property bloat. But in practice, they are are difficult to understand. It actually takes me a second to visualize the full set of triples and make sense of it.
In practice I have not used the "raw" :ComplexRelation class, but have instead created meaningful subclasses (:Ownership, :Allocation, :Responsibility, et sim). Similarly, I have also (sometimes) created subproperties of :isSubjectOfRel, et al, that carried semantic meaning. Examples: :isOwnershipOf, :isHeldByOwner, :isOwnedVia, and :holdsOwnership are subclasses of :hasRelObject, :hasRelSubject, :isObjectOfRel, and :isSubjectOfRel, respectively. So if we include the generic properties, then I would suggest including an editorial note suggesting that they be used solely as super-properties for semantically meaningful properties.

[uscholdm]

I don't know what you mean by "to reify both is perverse."

Lets assume that: gist:TemporalRelation rdfs:subClassOf gist:ComplexRelation . and that there are someValuesFrom restrictions for both hasRelSubject and hasRelObject on ComplexRelation.

Here is one way to define and use a class to represent a person being employed by a company for a period of time. It reifies a property called employs.

:EmploymentA rdfs:subClassOf gist:TemporalRelation  ;
	gist:reifiesProperty :employs .

:employs a owl:ObjectProperty ;
	rdfs:domain gist:Organization ;
	rdfs:range gist:Person .

:_EmploymentA_MfuBoeing97-08 a :Employment ;
	gist:hasRelSubject :_Organization_Boeing ;
	gist:hasRelObject :_Person_MFU ;
	gist:start :_TimeInstant_19Feb1997 ;
	gist:end :_TimeInstant_29Mar2008 ;
	. 

Here is an alternative, which reifies a property called employedBy. Memory clue: the 'B' in EmploymentB refers to the 'B' in the 'By' in isEmployedBy

:EmploymentB rdfs:subClassOf gist:TemporalRelation ;
	gist:reifiesProperty :employedBy .

:employedBy a owl:ObjectProperty ;
	rdfs:domain gist:Person ;
	rdfs:range gist:Organization .

:_EmploymentB_MfuBoeing97-08 a :Employment ;
	gist:hasRelSubject  :_Person_MFU;
	gist:hasRelObject :_Organization_Boeing ;
	gist:start :_TimeInstant_19Feb1997 ;
	gist:end :_TimeInstant_29Mar2008 ;
	. 

What happens if you define Employment to reify both properties?

:Employment rdfs:subClassOf gist:TemporalRelation ;
	gist:reifiesProperty :employedBy , :employs  .

:employedBy a owl:ObjectProperty ;
	rdfs:domain gist:Person ;
	rdfs:range gist:Organization ;
        owl:inverseOf :employs 
        .

To do this is perverse because doing so prevents you from being able say who is the employer vs. the employee.

:_Employment_MfuBoeing97-08 a :Employment ;
	gist:hasRelSubject  **???** ;
	gist:hasRelObject  **???** ;
	gist:start :_TimeInstant_19Feb1997 ;
	gist:end :_TimeInstant_29Mar2008 ;
	.

To have to say which relationship it reifies is perverse, IMO.

Well, its clearly not perverse to want to distinguish the employer from the employed - so how do you propose to do that if you reify both properties -- other than being forced to introduce extra properties, which defeats the purpose of hasRelSubject and hasRelObject.

[uscholdm]

@DanCarey404 said: "I am no longer in love with the generic properties to use with :ComplexRelation. "

The use of hasRelSubject and hasRelObject is optional. As Dan points out, it may be preferable to introduce properties with meaningful names. Thinking up such names is not always easy or useful. In those cases, having the generic properties helps. Boris and I have used them in a few cases. The people writing SPARQL queries are not offended, they just get on with it.

[rjyounes]

@uscholdm You are missing my point. The fact that that's impossible is why I don't like the properties. What I'm saying is:

1. It is arbitrary and misleading to associate the relationship object with one or the other of two inverse properties. Employment reifies hasEmployee just as much as hasEmployer.
2. Due to that, you have to either:
   a. Not use the hasRelSubject and hasRelObject properties, since as you correctly observe it is impossible to align the right subjects and objects with the right reified property.
   b. Reify only one of the two inverses, which I find illogical (aka perverse).

Also, can you explain what this model allows you to do that you cannot do otherwise?

[uscholdm]

Also, can you explain what this model allows you to do that you cannot do otherwise?

I cannot answer that question until I understand your proposal. Can you spell it out in triples, using the same example I used?

[uscholdm]

Reify only one of the two inverses, which I find illogical (aka perverse).

You are reifying a relationship. A relationship has a direction so you have to choose the direction. Nothing illogical so far. If you reify something that has a direction, the direction can't just vanish. The reified relationship has to faithfully maintain that direction. This seems perfectly straightforward - where is the logical inconsistency?

I look forward to seeing how your proposal maintains the direction so I can tell who is the employer and who is the employee.

[marksem]

Can't most of the ambiguity be solved by better class names, e.g. EmployerEmploysEmployeeRelation or OrgEmploysPerson or similar? Now the direction for :hasRelSubject and :hasRelObject is clear. And it would be further clarified given the annotation :reifiesProperty :employs.

[rjyounes]

@marksem So if you define both properties employs and isEmployedBy you'd have two classes, EmployerEmploysEmployeeRelation and EmployeeIsEmployedByEmployer Relation, when there is really just one type of relationship? Surely no one would like that.

@uscholdm We need to discuss this in person at a meeting because I've tried every way I can think of to explain my view and we're not communicating. There's one major point I apparently failed to make clear that may put everything else I'm saying in context: I am proposing that we not add this class and the related predicates.

[marksem]

@rjyounes You don't have to have 2 classes. (and you don't have to have the inverse either ;) These are modeling choices that add what I'd consider mostly redundant information to the graph.

[marksem]

As for an even better naming pattern, I suggest property named p implies class name pRelation. E.g. employs, and EmploysRelation. Assuming the property name is unambiguous, the class name will also be unambiguous (as to what hasRelSubject and hasRelObject point to).

[uscholdm]

As for an even better naming pattern, I suggest property named p implies class name pRelation. E.g. employs, and EmploysRelation. Assuming the property name is unambiguous, the class name will also be unambiguous (as to what hasRelSubject and hasRelObject point to).

This is an interesting creative and reasonable naming convention.

[uscholdm]

There's one major point I apparently failed to make clear that may put everything else I'm saying in context: I am proposing that we not add this class and the related predicates.

That is a proposal for what to NOT do. What to you propose TO do as an alternative to the employment example I spelled out the triples for? Can you provide an alternate set of triples?

A few triples is worth a thousand words. This may help us get to the nub of the different points of view. Not just for me, but it will make it clear to everyone what options are on the table.

[uscholdm]

@marksem

@rjyounes You don't have to have 2 classes. (and you don't have to have the inverse either ;) These are modeling choices that add what I'd consider mostly redundant information to the graph.

I completely agree.

[rjyounes]

@marksem @uscholdm Agreed, but the arbitrariness of which property is declared as the refied property nevertheless disturbs me.

In terms of redundant information, no one has explained how the ComplexRelationship class itself provides non-redundant information.

Another thing I'd like an example of: the idea of a superclass of TemporalRelation that is not time-bound is interesting, but are there in fact such relationships? If not, then we can continue to use TemporalRelation with no time specifications where we don't know them or care about them.

[uscholdm]

@DanCarey404 may have examples at MS. We have a timeless example in Platts: https://agraph.semanticarts.com/#/catalogs/platts/repositories/platts-demo1/node/%3Chttps://ontologies.platts.com/pleo/SymbolPlacement%3E

The definition needs to be improved, however, I forget what it was about.

Statements with a subject of pleo:SymbolPlacement

Predicate	Object
rdfs:isDefinedBy	pleoAnnotation
skos:prefLabel	"Symbol Placement"
rdfs:subClassOf	gist:ComplexRelationship
rdfs:subClassOf	_:b8C15FD54x14180
rdfs:subClassOf	_:b8C15FD54x14182
skos:definition	"The reification of the relationship indicating what DataGrid a Symbol is presentedIn. Enables to the placement within a data grid to be characterizes. Also includes any hierarchy overrides"
rdf:type	owl:Class

[rjyounes]

Closing: Consensus is that this is a design pattern rather than a class.