Open uscholdm opened 3 years ago
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.
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
andhasEmployee
, 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.
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.
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.
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.
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
.
@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.
@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:
Employment
reifies hasEmployee
just as much as hasEmployer
.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?
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?
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.
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.
@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.
@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.
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).
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.
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.
@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.
@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.
@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 |
Closing: Consensus is that this is a design pattern rather than a class.
We have this at two of our clients. It looks like this: