Address semantic issues related to OrdinalCollection and OrdinalMember

[rjyounes]

OrdinalMember is not so much a type of thing as the relationship between a thing and an OrdinalCollection. Something can be a member of more than one OrdinalCollection just as it can be a member of more than one Collection in general. For example, 3 is a member of the ordinal collection of integers and of prime numbers.

Granted, the semantics of OrdinalCollection will not be as tightly constrained as they are now without the OrdinalMember class, but they will be more accurate.

This also requires that precedence relationships not be stated directly between the members, but through ordering proxies -- e.g., the OAI-ORE ontology. That is, in the collection of integers 3 directly precedes 4, but in the collection of prime numbers it directly precedes 5. The relationships don't make sense unless stated relative to a specific collection.

On the other hand, the intent of the OrdinalCollection and OrdinalMember classes may be to limit them to sequences like the months of the year or days of the week, where members are part of only one (well-established) collection. In that case, we must say that the sequences of integers and primes are OrderedCollections but not OrdinalCollections. Then the restriction on OrdinalMember that it can be part of only one OrdinalCollection should be formalized in the OWL definition since it's crucial to the semantics.

[uscholdm]

* OrdinalMember is not a type of thing; Yes, OrdinalMember is more a role that something plays. It is a class so it can be used in restrictions, domains and ranges. Not ideal. There is probably a better way. There is nothing interesting * there's a relationship between a thing and an OrdinalCollection There is nothing interesting about the relationship between and OrdinalMember and an OrdinalCollection: its gist:memberOf. An OrdinalCollection is meant to be used as a set of possible values for a measure that are ordered. * This also requires that precedence relationships not be stated directly between the members, but through ordering proxies. That is, in the collection of integers 3 directly precedes 4, but in the collection of prime numbers it directly precedes 5. The relationships don't make sense unless stated relative to a specific collection. * And we should state this restriction on OrdinalMember that it can be part of only one OrdinalCollection. Excellent points. Do you have any specific suggestions to improve this? From: Rebecca Younes <notifications@github.com> Sent: Sunday, 22 September, 2019 06:32 To: semanticarts/gist <gist@noreply.github.com> Cc: Subscribed <subscribed@noreply.github.com> Subject: [semanticarts/gist] Should OrdinalMember be a class? (#112) OrdinalMember is not a type of thing; there's a relationship between a thing and an OrdinalCollection. Something can be a member of more than one OrdinalCollection just as it can be a member of more than one Collection in general. For example, 3 is a member of the ordinal collection of integers and of prime numbers. Granted, the semantics of OrdinalCollection will not be as tightly constrained as they are now without the OrdinalMember class, but the semantics will be more accurate. This also requires that precedence relationships not be stated directly between the members, but through ordering proxies. That is, in the collection of integers 3 directly precedes 4, but in the collection of prime numbers it directly precedes 5. The relationships don't make sense unless stated relative to a specific collection. The intent of the OrdinalCollection and OrdinalMember classes may have been to limit them to sequences like the months of the year or days of the week, where members are generally part of only one collection. In that case, do we want to say that the sequence of integers or primes is an OrderedCollection but not an OrdinalCollection? And we should state this restriction on OrdinalMember that it can be part of only one OrdinalCollection. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub<#112?email_source=notifications&email_token=ACSHHSKT3BEHXR5U2DJJVPTQK5XVJA5CNFSM4IZCTCAKYY3PNVWWK3TUL52HS4DFUVEXG43VMWVGG33NNVSW45C7NFSM4HM4IEKQ>, or mute the thread<https://github.com/notifications/unsubscribe-auth/ACSHHSPG52JQSM3ZFRI5CY3QK5XVJANCNFSM4IZCTCAA>.

[johnwcowan]

I think the way forward is to have a class Ordering that describes the order of elements. Then an OrderedCollection is a pair <Collection, Ordering>.

[marksem]

Related: #142

[rjyounes]

@johnwcowan I would instead propose a proxy object that sits between a collection and a member which specifies the order. This is the OAI-ORE approach. It's easier to query what position a member occupies in the list. Further, if you have an infinite ordered collection, such as the set of positive integers, you cannot actually provide an Ordering, while you can state that the integer 245678 occupies position 245678.

Sample RDF (this example is a little awkward because 5 is a literal and we probably don't want to autobox it in an object, so we cannot make an inverse assertion from 5 to the proxy.

:positiveIntegers a gist:OrdinalCollection .
:proxyFor5InPositiveIntegers gist:memberOf :positiveIntegers ;
    :sequence "5"^^xsd:int ;
    gist:decimalValue "5"^^xsd:decimal .

:primeNumbers a gist:OrdinalCollection .
:proxyFor5InPrimeNumbers gist:memberOf :primeNumbers ;
     :sequence "4"^^xsd:int ;
     gist:decimalValue "5"^^xsd:decimal .

[uscholdm]

Currently, hasOrderedMember is inverse functional. This prevents having one item be in more than one OrderedCollection. A way to get around this is as follows. Lets say:

• we have 10 objects: Obj1 through Obj10 and 3 lists: OrdList1, Ordlist2 and OrdList3.
• Obj1 is first in OrdList2, and is in third place in OrdList1 and OrdList3.

One way to model this is to create a class called say ItemInSequence. To model the above situation we would have two instances of this class -- one for Obj1 in first place and one for it in third place. In Turtle (and Manchester)

OrdList1 a gist:OrderedCollection .
OrdList2 a gist:OrderedCollection .
OrdList3 a gist:OrderedCollection .

Obj1_1 a :ItemInSequence ; gist:sequence 1, gist:memberOf OrdList2.
Obj1_3 a :ItemInSequence ; gist:sequence 3, gist:memberOf OrdList1 , OrdList3.

ItemInSequence is used instead of the bogus OrderedMember, which is now gone from gist.

For a subclass of OrderedCollection to be used this way, you might want some SHACL to say that every member is an instance of ItemInSequence. It would work to have it be a restriction on OrderedCollection because there is another way to create ordered collection - -namely by using the precedes/precededBy property with ordinary objects as members. Their sequence could be inferred.

There is a downside to this: if you want to reorder things in the list, its a big pain.
@markwallace encountered this a while back. Mark: what was your experience?

[rjyounes]

@uscholdm I believe you are missing the relationship between Obj1 and the item in sequence Obj1_1. If that's added in, this is the same as the proxy approach I've outlined above, unless there's some distinction I've missed.

[johnwcowan]

Yes, that confused me too. You also could have two subclasses of SequenceItem (better than ItemInSequence, I think), one being LinkedSequenceItem where the SequenceItems are connected by precedes/precededBy (or just precedes/follows), and the other being NumberedSequenceItem, which uses sequence numbers. These correspond to linked lists and vectors: one is good for local insertion and deletion, the other is good for access to the nth element.

…

On Tue, Jul 7, 2020 at 11:55 AM Rebecca Younes ***@***.***> wrote: @uscholdm <https://github.com/uscholdm> I believe you are missing the relationship between Obj1 and the item in sequence Obj1_1. If that's added in, this is the same as the proxy approach I've outlined above, unless there's some distinction I've missed. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#112 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AANPPBRKQE7KD3LI47ROLHTR2NANNANCNFSM4IZCTCAA> .

[rjyounes]

I like the idea of using precedes/precededBy for insertion and deletion. Not in favor of dual methods for representing the same semantics, and especially not on the same collection since duplication is a recipe for getting things out of sync.

[marksem]

May want to have a look at OLO (ordered list ontology). It has a "slot" concept that allows items to be in more than 1 ordered collection.
http://smiy.sourceforge.net/olo/spec/orderedlistontology.html

Example:

@prefix dc:      <http://purl.org/dc/elements/1.1/> .
@prefix olo:     <http://purl.org/ontology/olo/core#> .
@prefix mo:      <http://purl.org/ontology/mo/> .
@prefix ex:      <http://example.org/> .
 
ex:FunkyPlaylist a olo:OrderedList ;
   dc:title "Funky Playlist"^^xsd:string ;
   dc:description "A playlist full of funky legends"^^xsd:string ;
   dc:creator <http://foaf.me/zazi#me> ;
      olo:length 2 ;
      olo:slot [   
         olo:index 1 ;
         olo:item ex:SexMachine
      ] ;
      olo:slot [
         olo:index 2 ;
         olo:item ex:GoodFoot
      ] .
 
ex:SexMachine a mo:Track ;
   dc:title "Sex Machine"^^xsd:string ;
   dc:creator <http://dbpedia.org/resource/James_Brown> .
 
ex:GoodFoot a mo:Track ;
   dc:title "Good Foot"^^xsd:string .	

This is the same as my (@uscholdm) approach except it uses blank nodes.

[daliadahleh]

If that's added in, this is the same as the proxy approach I've outlined above, unless there's some distinction I've missed.

I believe the difference is that Michael is using an instance per position, rather than an instance per collection. I.e. the instance Obj1_3 can be used in multiple collections as long as it has position 3 in all of those collections.

I prefer an instance per collection, even though it means a slightly larger number of triples, mostly because I prefer to use directlyPrecedes rather than sequence (and this approach will only work with sequence). If you prefer to use sequence, I don't see why an instance per position wouldn't work.

[rjyounes]

While this may be technically true, my objection is that this is a semantically unpalatable type of object: an instance which happens to be in 3rd position in any collection. In other words, the notion of "March when it is in 3rd position" in the collection Months vs "March when it is in 2nd position" as in the collection of Months with 31 Days makes no sense to me. March is March. And you would need a predicate that would relate the two Marches, since otherwise they are as unconnected as March and November; thus expanding the number of triples. In any case, the number of triples is of less significance than correctly capturing the semantics, and the proxy solution is preferable in this regard.