Jay: I'm reviewing the names of the relationships in the temporal relations for a couple of Jira tickets and have a couple of ideas I wanted to run by you. The names are confusing because the semantics of the relation is already given by the name/definition and having relationships to members named after the temporal relation name and its converse is not correct. For instance, ContainsTemporalRelation has two relationships, contains and during, which doesn't work because they point to members rather than to other relations.  



Options: 



1) What do you think of having generic names? Like source and target, or even subject and object as in RDF (we can view the relation as a predicate in which case subject and object makes sense). 




2) How about not having new relationships at all and just using fuzzyPredecessor and fuzzySuccessor from the superclass? In fact, that's what they are in all Allen's predicates (except Equals)




I prefer 2) a little bit more, but as long as we deal separately with Equals, which is not an order relation at all, it's rather an equivalence relation.




Flavio

I just noticed that in addition to Equals there are two other Allen's relations, and their converses, that are not orders.  



Summary:




- Equals is an equivalence relation, i.e reflexive, symmetric and transitive.

- Meets is anti-transitive: from a meets b and b meets  c it follows that a doesn't meet c.

- Overlaps is not transitive: from a overlaps b and b overlaps c it doesn't necessarily follow that a overlaps c (but it might)




All others are order relations. 






One solution is to have a generic "Relation" object as I suggested in another thread over the weekend, and then have subclasses for orders and equivalences. We might try to think of other alternatives as well.





Flavio

Yes. I decided that the collection of interval pairs is not an OrderRelation and the interval pairs in the collection are not all OrderRelationPairs.




My solution is to call the collection of interval pairs a TemporalIntervalRelation. It does NOT implement an OrderRelation. Each pair contained in this collection is a TemporalIntervalPair. It does NOT implement an OrderrelationPair. Instead TemporalIntervalPair is abstract (no relationships are indicated) and is specialized by the 7 interval pair types that form Allen’s interval algebra + a fuzzy one. Each TemporalIntervalPair has a relation and a converse as specified by the algebra. In the case of the CoextensiveIntervalPair the relation and its converse are essentially the same — Equal — so hence EqualA and EqualB.




It turns out that not all mixes of pairs are tractable (satisfiable). I think 18 mixes have been determined to be tractable. Each is called a tractable subalgebra. However, across these mixes transitivity is not guaranteed. If the only type of pair someone uses in the collection of pairs (TemporalIntervalRelation) is a FuzzzyPrecedesIntervalPair, then in fact you have transitivity, and in this instance a TemporalIntervalRelation is an OrderRelation. There are probably other instances TemporalIntervalRelations that are also OrderRelations but I haven’t sorted that out.




I implemented all of this in Drupal so it is easier to evaluate. I spent a lot of time with the documentation of TemporalIntervalRelation. I said what I have said here but in a little more detail.




I did adopt your suggestion to make ControlConstruct reflexive. Also in addition to an Act extending a ProcessStep now it has a relationship with ProcessStep: a ProcessStep performs an act. So now a ProcessStep performsAct and isPerformedByService. In this approach a ProcessStep can be atomic and simply terminate in an act or it can be composite with nested control constructs that themselves can terminate in acts.




Finally, at least in documentation and also with a property I have begun to address the issue you raised that there are basically three different types of ExecutionPairs. OWL-S it turns out is also aware of this so I used both your thinking and some OWL-S thinking to discuss and specify the three types.


Determining the type of relations resulting of mixing different types is hard, in most cases you have more than one possibility. For instance, a overlaps b and b overlaps c can result in either a overlaps  c, a meets c, or a precedes c, depending on the start and end points of a, b and c. But within a single type it's easy to determine whether the relation is an order, an equivalence or neither.

 - Precedes: order
 - Meets: anti-reflexive, anti-symmetric and anti-transitive
- Overlaps: anti-reflexive and anti-symmetric
 - Finished by: order
 - Contains: order
 - Starts: order
 - Equals: equivalence

 They are easy to prove. The converses have the same properties. 

 I think we need to review the model, we can still say that the order relations are in fact OrderRelations in DDI4. We should discuss this today if possible.

 Flavio