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.