Generalize OrderedCollection/OrderedMember model

[rjyounes]

An OrderedMember is an object that sits between an OrderedCollection and its "real world" member to provide the order of that entity in the collection; given that the same object can have different positions in different collections, you cannot put the order on the thing itself. The predicate providesOrderFor links the OrderedMember to that entity, and has either a sequence number or precedence relationships.

I have a use case for a temporal Membership relation between something and a collection. It can hold dates and potentially other information about that membership (e.g., who added it?). It strikes me that this is a generalization of our OrderedMember, and that if we replace OrderedMember with Membership the same object can store sequence, precedence, temporal relations, and any other information about that membership.

Predicate from Membership to Collection: isMemberOf. Along the lines of offers either directly connecting an offer giver to the thing being offered, or an offer node that sits between them (see issue #1102). If that's not palatable (a membership is not really a member), maybe isMembershipIn.
Predicate from Membership to thing: I propose isMembershipOf. hasMember is smoother but runs the risk of appearing to be the inverse of isMemberOf.

[rjyounes]

See also #424 for a more general way of defining the predicates.

[uscholdm]

Interesting observation. I have used Membership as follows for client engagements:

ex:Membership
	a owl:Class ;
	rdfs:subClassOf
		gist:TemporalRelation ,
		[
			a owl:Restriction ;
			owl:onProperty ex:isMembershipBy ; # the 'act' of being a member is being done BY the member
			owl:someValuesFrom owl:Thing ;
		] ,
		[
			a owl:Restriction ;
			owl:onProperty ex:isMembershipOf ; # membership OF a collective entity
			owl:someValuesFrom owl:Thing ;
		]
		;
	skos:definition
		""^^xsd:string ,
		"Something being a member of something for a period of time."^^xsd:string
		;
	skos:prefLabel "Membership"^^xsd:string ;
	.

If OrderedMember is to be a subclass then Membership cannot be a subclass of TemporalRelation because there is no necessary temporal element to being a member of an ordered collection.

I also think that an ordered collection is important enough to exist on its own, using a providesOrderFor property.

In short, it seems to work ontologically, strictly speaking. But it might not be worth doing. We'd have to create a non-temporal membership class with OrderedMembership as one variant and temporal another nondisjoint variant. Can't think of a good way to leverage the commonality you saw.

[rjyounes]

Membership is not necessarily temporal, so not subclass of TemporalRelation.

But we don't want Membership at the top of the hierarchy. So we could introduce ComplexRelation(ship) (or whatever we want to call it), with Membership reifying isMemberOf.

Alternate names for ComplexRelation(ship). Options:

• ReifiedRelation(ship)
• Relationship
• ContextualizedRelationship

Dan: deprecate TemporalRelation? Just add temporal information on the relationship.
Rebecca: Is it useful to define relationships that are by nature temporal?
Michael: yes

To do: Rebecca will provide sample triples.

[uscholdm]

@rjyounes The first part of this deck from many years ago (2012) explains the relationship between a reified relationship and a temporal relation. Best to watch the animations. This predated the class ComplexRelationship
TemporalRelationsV1.pptx

[rjyounes]

@uscholdm Here are the promised triple examples. I think this is in line with your slide deck.

Proposed Membership Model

gist 13.0.0

Ordered Collection Model

• Classes: OrderedCollection, OrderedMember
• Properties: providesOrderFor, isMemberOf; one or more of sequence, precedesDirectly, precedes

Example

exo:RaceRanking
    a owl:Class ;
    rdfs:subClassOf gist:OrderedCollection ;
    .

exd:_Person_tadej_pogacar a gist:Person .
exd:_Person_jonas_vingegaard a gist:Person .

exd:_RaceRanking_tdf_2024_stage_11
    a exo:RaceRanking;
    .

exd:_OrderedMember_tdf_2024_stage_11_jonas_vingegaard
    a gist:OrderedMember ;
    gist:isMemberOf exd:_RaceRanking_tdf_2024_stage_11 ;
    gist:sequence 1 ;
    gist:providesOrderFor exd:_Person_jonas_vingegaard ;
    .

exd:_OrderedMember_tdf_2024_stage_11_tadej_pogacar
    a gist:OrderedMember ;
    gist:isMemberOf exd:_RaceRanking_tdf_2024_stage_11 ;
    gist:sequence 2 ;
    gist:providesOrderFor exd:_Person_tadej_pogacar ;
    .

exd:_RaceRanking_tdf_2024_stage_21
    a exo:RaceRanking;
    .

exd:_OrderedMember_tdf_2024_stage_21_tadej_pogacar
    a gist:OrderedMember ;
    gist:isMemberOf exd:_RaceRanking_tdf_2024_stage_21 ;
    gist:sequence 1 ;
    gist:providesOrderFor exd:_Person_tadej_pogacar ;
    .

exd:_OrderedMember_tdf_2024_stage_21_jonas_vingegaard
    a gist:OrderedMember ;
    gist:isMemberOf exd:_RaceRanking_tdf_2024_stage_21 ;
    gist:sequence 2 ;
    gist:providesOrderFor exd:_Person_jonas_vingegaard ;
    .

Other information about the relationship, such as finishing times, can also be hung off the OrderedMember instances.

gist 13.1.0 Proposal: Membership Class

• New class: Membership
• New properties: isMembershipIn, isMembershipOf (but see below on a potential generalization)
• Deprecate: OrderedMember, providesOrderFor

Examples

Ordered Collections

These work the same as before, with updated classes and predicates:

exd:_RaceRanking_tdf_2024_stage_11
    a exo:RaceRanking;
    .

exd:_Membership_tdf_2024_stage_11_jonas_vingegaard
    a gist:Membership ;
    gist:isMembershipIn exd:_RaceRanking_tdf_2024_stage_11 ;
    gist:sequence 1 ;
    gist:isMembershipOf exd:_Person_jonas_vingegaard ;
    .

exd:_Membership_tdf_2024_stage_11_tadej_pogacar
    a gist:Membership ;
    gist:isMembershipIn exd:_RaceRanking_tdf_2024_stage_11 ;
    gist:sequence 2 ;
    gist:isMembershipOf exd:_Person_tadej_pogacar ;
    .

What's new is that the Membership class, unlike OrderedMember, can be used with unordered collections - and other things that can have members, such as organizations - to provide contextual information beyond what the direct predicate isMemberOf can express.

Unordered Collections

exd:_Collection_my_favorite_books a gist:Collection .

exd:_Membership_my_favorite_books_the_magic_mountain
    a gist:Membership ;
    gist:isMembershipIn exd:_Collection_my_favorite_books ;
    gist:isMembershipOf exd:_Book_the_magic_mountain ;
    gist:actualStartDate "1990-04-01T00:00:00"^^xsd:dateTime ;
    # On a second reading, I didn't like it so much.
    gist:actualEndDate "2010-07-26T00:00:00"^^xsd:dateTime ;
    .

Organization Membership

exo:Team
    a owl:Class ;
    rdfs:subClassOf gist:Organization ;
    .

exd:_Team_jumbo_visma a exo:Team .
exd:_Team_bora_hansgrohe a exo:Team .
exd:_Person_primoz_roglic a gist:Person .

exd:_Membership_jumbo_visma_primoz_roglic
    a gist:Membership ;
    gist:isMembershipIn exd:_Team_jumbo_visma ;
    gist:isMembershipOf exd:_Person_primoz_roglic .
    gist:actualStartDate "2016-01-01T00:00:00"^^xsd:dateTime ;
    gist:actualEndDate "2023-01-01T00:00:00"^^xsd:dateTime ;  
    .

exd:_Membership_bora_hansgrohe_primoz_roglic
    a gist:Membership ;
    gist:isMembershipIn exd:_Team_bora_hansgrohe ;
    gist:isMembershipOf exd:_Person_primoz_roglic .
    gist:actualStartDate "2024-01-01T00:00:00"^^xsd:dateTime ;
    .

Contextualized Relationships

Membership is not a subclass of TemporalRelation because it is not inherently time-delimited, though some individual instances may be, as in the examples. We don't want to put it at the top of the class hierarchy, and moreover it is reasonable to expect that we would want to define other such classes in the future either in gist or in extension ontologies. One that comes to mind is Contribution, as in an author or illustrator contribution to a work. The instance can have a category attached to specify the specific role. This is not time-delimited because once true it holds true for ever, even after the death of the author. (Certainly it has a start date, but only because the work has not existed since the beginning of time. I don't consider that a real start date.)

This leads to the proposal of a top-level class ContextualizedRelationship (name subject to change; this is a placeholder) that is used to provide contextual information about a relationship that cannot be done with a direct object property (without the use of RDF*). The class TemporalRelation could be a subclass, or could be eliminated altogether in favor of just adding dates to particular instances. The question of whether it is important to distinguish inherently time-delimited relationships from those that aren't is subject to debate (I happen to think it is; it's semantically significant that, say, an employment relationship is time-delimited but the relationship of an author to a book is not.)

Issue #424 proposes such a class, accompanied by a predicate reifiesProperty (I would suggest reifiesRelationship instead, to suggest semantics rather than syntax). In the case of the subclass Membership, the reified property is isMemberOf.

The proposal also includes generalized predicates hasRelSubject and hasRelObject so that individual predicates like isMembershipIn and isMembershipOf don't have to be defined for each specialization of ContextualizedRelationship. Since our predicate is isMemberOf, we would use hasRelSubject to link to the member, and hasRelObject to link to the collection, organization, etc.

My opinion: if we want to adopt the Membership class, we should also define the superclass for complex/ reified/contextualized relationships. Open questions:

• Name for the superclass
• Deprecate TemporalRelation or make subclass of the new superclass?
• General predicates vs specific ones.
• Should we always define the corresponding direct object property?
  • If not, which direction would the general properties go in when it doesn't exist?

[philblackwood]

Some possible reification patterns to reify :owns, :hasParticipant, :contributesTo etc.

The goal of the exercise is to see if common patterns can be used.

reification patterns.pptx

[uscholdm]

Some possible reification patterns to reify :owns, :hasParticipant, :contributesTo etc.

The goal of the exercise is to see if common patterns can be used.

reification patterns.pptx

This is good input.