Allow empty collections

[kaspar-p]

This was discussed during the gist overview during the 2021 Summit.

The empty set (and by extension, empty list) is an important concept and widely useful.

For a use-case, imagine there were a university professor that had a course, and wanted to keep an OrderedCollection of students with the order basis being their grade (0-100). For administrative purposes, it would be nice to add the course into the data, and give it this ordering, before actually having students with grades.

Note that in the above example, student-with-grade would be the proxy object for student. The course might be full of students, though none of them have grades yet. The structure of having an OrderedCollection would be useful at that moment.

The current implementation defines a gist:OrderedCollection as something that has OrderedMember's, but perhaps an alternative definition defines the fact that gist:OrderedCollection's contain 0 or more OrderedMember's. This keeps the scope to being OrderedMembers, but might also include emptiness.

[rjyounes]

The issue is in gist:Collection, not gist:OrderedCollection, and needs to be fixed there. I'm adapting the title to reflect this.

[uscholdm]

I agree that empty collections are useful. It could be a queue that changes over time, and might be empty.
The downside is that there is no longer anything definitive in owl that we can say about hasMember other than a min 0 restriction. In this case, I think its ok. There really isn't anything that needs to be said. SHACL can have a * constraint which is like a min 0 restriction.

[rjyounes]

It robs Collection of any formal semantics. However, that may be worth the tradeoff of allowing empty collections, which I agree makes sense.

[wslooney]

I'm working on this issue now, and I'd like to get feedback on 3 things:

(1) To allow for empty collections, gist:Collection could look like this:

gist:Collection
	a owl:Class ;
	rdfs:subClassOf [
		a owl:Restriction ;
		owl:onProperty gist:hasMember ;
		owl:allValuesFrom owl:Thing ;
	] ;
	skos:definition "Any identifiable grouping of instances.  For instance, a jury is a collection of people."^^xsd:string ;
	skos:example "A jury is a group of people,   a financial ledger is a collection of transaction entries; a route is an (ordered) collection of segments."^^xsd:string ;
	skos:prefLabel "Collection"^^xsd:string ;
	.

Like what was said in previous comments, every owl class is a subClass of the class restriction above, so it's inert. However, it (a) establishes a pattern for creating subclasses and (b) it hints that the gist:hasMember property is the right property to use for collection members. Even with this vacuously true restriction, gist:Collection does still have some semantics because it is the superclass of all other collections.

(2) I'm assuming we also want to make empty groups possible, but I have a question about gist:Group. Currently there's a restriction:

a owl:Restriction ;
owl:onProperty gist:hasMember ;
owl:someValuesFrom gist:Person ;

which (a) does not allow for empty groups and (b) allows for non-person members of groups. The skos:definition suggests it should not allow for non-person members:
skos:definition "A collection of People. The group may or may not be an Organization. Many organizations consist of groups of people, but that is not a defining characteristic."^^xsd:string
In that case using the pattern in (1) should work here as well swapping owl:Thing for gist:Person.

(3) This one should be it's own issue, but probing whether it should be raised or not. Should gist:OrderedMember have a restriction such that it must have a gist:providesOrderFor relation to something? The property is functional so it would not need to be a cardinality restriction.

[uscholdm]

We are moving in the direction of SHACL instead of 'inert' axioms. Other examples are min 0 restrictions. The idea is that hints can be placed in annotations. We now use domainIncludes and rangeIncludes to replace min 0. Here is a proposed variation, which changes the definition.

gist:Collection
	a owl:Class ;
	skos:definition "A grouping of things."^^xsd:string ;
        skos:scopeNote "Individuals are placed in the collection using the gist:hasMember property. Collections typically are created because the members are functionally connected in some way. This definition allows a collection to have zero members."^^xsd:string ; 
	skos:example "A jury is a group of people,   a financial ledger is a collection of transaction entries; a route is an (ordered) collection of segments. A deck of playing cards."^^xsd:string ;
	skos:prefLabel "Collection"^^xsd:string ;
	.

The use of the word 'grouping' in the definition conflicts with gist:Group. I propose to get rid of gist:Group. I have never used it. If we did want it, it should have a more specific name, such as GroupOfPersons. It would be defined as a subclass of gist:Collection and have an allValuesFRom restirciton with gist:Person as the filter class. But I cannot see any reason to keep it.

[wslooney]

Thanks @uscholdm. I think what you've said about gist:Collection is correct. I suspect you're right about eliminating gist:Group but I think that exceeds my mandate. I'll raise another issue about eliminating gist:Group but in the meantime, I'll plan on changing it to allow for empty Groups, unless anyone has a strong reason not to.

[rjyounes]

I am not sure about empty groups as opposed to collections. Let's hold off on changing it and add an issue to determine whether Group should be removed. Then it's a moot issue.

The only problem with allowing empty collections is that Collection then has no semantics. But I agree with Michael that restrictions should not be used to provide usage hints.

I also agree with your proposed restriction on OrderedMember. But in order to prevent scope creep on these issues, that will also need to be a separate issue. If you assign it to yourself, you could still submit one PR for both (add it to the project as well).

[rjyounes]

Regarding empty collections: we all know that mathematically a set may have no members. But we are dealing with the real world: are there use cases for empty collections?

[wslooney]

There's an imagined use case in the initial comment, though I'm not confident it really motivates allowing for empty Collections. To say there's a collection that hasn't been populated yet is very different from saying there's an empty collection.

@rjyounes we discussed this issue when you were out of town, but I'd like to revisit it again to make sure we really want to do this.

[Jamie-SA]

Examples of empty Collections:

• MFU mentioned a queue. Could be a queue of jobs to be run, that is sometime empty.
• stock trade portfolios, you could sell off your stocks but not close the account
• an Inbox (though you could argue collections might not be the best model)
• music playlists

[rjyounes]

Understood that these are examples of empty collections, but what I'm wondering is if we ever have a need to model them.

@wslooney I don't understand your distinction between an empty collection and one that hasn't been populated yet, from either a logical or a modeling perspective. Yes, we will discuss this again today.

[wslooney]

A knowledge graph reflect the state of knowledge at a moment in time, not the state of the world at a moment in time. In the case of the university gradebook that hasn't been populated yet, I'm thinking of like an even that hasn't started yet. That is has no hasMember relations reflects the knowledge that we don't yet have about who the members are, it doesn't reflect that its a memberless gradebook.

I grant that there may be other cases however where we can't think of this way. For example for inventory, we may have a collection grouping of all the eggs and the grouping gets updated each day with the time of the update and number of eggs at the time of the update. If it's sold out the grouping is empty, and it's not matter of temporality.

[rjyounes]

The conceptual difference is clear, but any empty collection is represented in the graph in the same way: a Collection instance with no members. Therefore, I don't see how this distinction is relevant to the ontology.

The crux of the issue is still whether we have a use case for empty collections.

[rjyounes]

Decision: Allow empty collections, meaning:

• Remove restriction on Collection
• Add scope notes to Collection indicating it can be empty; use hasMember to add members; use SHACL if data prohibits non-empty collections
• Modify scope note on OrderedCollection

[rjyounes]

Changes inferencing in a way that no one is likely to care about, so we don't consider this a major change.

[rjyounes]

Fixed in gist 11.1.0.