Re: defining the semantics of lists

On 6/10/2020 2:07 PM, Frans Knibbe wrote:
> Hi all,
> 
> Perhaps a worthy example of using a list is defining geometric shapes by 
> using an array of coordinates. A very simple example would be a triangle 
> defined by the sequence (1,1) (2,3) (3,2) (1,1), with the numbers in 
> brackets being x,y values. In this list, completeness is important, 
> otherwise the described shape will be malformed or unclosed. Order is 
> also important: if the list elements are not reproduced in the right 
> order, the described shape will be malformed (in other words, the 
> knowledge will not be correctly represented). 

I would rather model this as a triangle entity with "edge" relationships 
to three "Edge" objects.  Each Edge would have a relationship (perhaps 
"connectsTo") with a Point, and also an "order" property.

(An alternate model for a triangle could be that it has exactly three 
Sides, each of which has a length property.  You don't really need the 
points at all, since the intersection of two lines is a point). 
Geometrically, the lengths of three sides are enough to specify a the 
shape of a triangle (except for mirror images);  if necessary, a side 
could have a start and end coordinate, if you need to locate the 
triangle in space instead of just knowing its shape.  But a model like 
this would not be general enough for other list-like applications).

This model is fully compatible with rdf, unambiguously describes the 
triangle (well, maybe you would want to add a rotation direction 
property to the order property if you cared about mirror images), and 
does not require any new rdf machinery.  Software that understands 
triangles can use the order property to order the points however it wants.

In OWL, you could restrict the number of edge objects of a Triangle to 
three, if you cared to, and state that the "Edge" object must have 
exactly 1 Order property and one Point property.

You may say that it seems complicated to replace a collection of points 
by three edge properties and Edge objects, with each Edge having a 
relationship with a Point and an order value.  But as we've seen over 
the last weeks on this thread, the new semantics to add a list to rdf 
would be complex, make interpretations hard to arrive at, and would not 
be supported by current software.  And anyway, the complexities come 
from the nature of the modeled thing - here, a triangle.  A triangle is 
associated with three points, the nature of that association has certain 
properties, and if you want to describe a triangle you simply have to 
include all of that.  Hiding those things with a new list syntax doesn't 
eliminate them, but may encourage mistakes in understanding of what is 
meant.

In addition, with this model, any point can participate in other 
geometrical figures without any problems.

I doubt that there are any cases where you couldn't model a list in a 
similar way if you really need the equivalent of a list.  It's more a 
matter of modeling than anything else.  rdf collections are not always 
suited for modeling of this kind, but that doesn't mean that adding a 
new list syntax would a better way to go.  Better that software that 
wants to use lists would construct them from the rdf model.

It will (or should!) take a long time to get consensus on the semantics 
of lists, but with a good model such as the one above, you can be using 
it tomorrow.

> Next to that, if the shape 
> is defined within a reference framework, the sequence can be used to 
> describe an area inside of the triangle or outside of it. Common 
> practice in Geographic Information Systems (GIS) is to use the rotation 
> in which the coordinates are connected (clockwise or anti-clockwise) to 
> indicate what is meant.
> 
> Greetings,
> Frans
> 
> Op wo 10 jun. 2020 om 19:42 schreef Hugh Glaser <hugh@glasers.org 
> <mailto:hugh@glasers.org>>:
> 
>     Hi Thomas P,
> 
>     I had a feeling you didn't want to :-)
>     Thanks for doing it.
>     But as you probably expected, I agree with Thomas L - why on earth
>     would you want to use a list for your unordered favourite colours?
>     That would force you to decide on an ordering, and worse still the
>     ordering might appear to have some meaning.
>     Surely three simply triples is a much better representation of this
>     knowledge?
> 
>     [And I know that hans.teijgeler@quicknet.nl
>     <mailto:hans.teijgeler@quicknet.nl> said "For each of those you guys
>     will undoubtedly invent some workaround, but that isn't good
>     enough.". I don't think that is a workaround - it a correction of
>     actually incorrect representation of the knowledge.]
> 
>     I am reminded of trying to program in languages with poor qualities
>     for the representation of complex data structures (such as Lisp),
>     where you end up squeezing everything into the same single structure
>     - a list or perhaps an array.
> 
>     Massaging data structuring and deforming the data into your
>     favourite construct is not a good way to go about programming, methinks.
> 
>     Have you got any better examples, perhaps?
> 
>     Best
>     Hugh
> 
>      > On 8 Jun 2020, at 16:20, Thomas Passin <tpassin@tompassin.net
>     <mailto:tpassin@tompassin.net>> wrote:
>      >
>      > On 6/8/2020 10:26 AM, thomas lörtsch wrote:
>      >>> On 8. Jun 2020, at 14:07, Hugh Glaser <hugh@glasers.org
>     <mailto:hugh@glasers.org>> wrote:
>      >>>
>      >>> Hi Thomas,
>      > [snip]
>      >
>      >>> As a specific example of my problem, below you say: "I don’t
>     see the pressing need for empty lists."
>      >>> I think that means you have ideas of applications in mind - if
>     you can expose those, please, that would be great.
>      >> I didn’t for two reasons:
>      >> - lists are such a fundamental concept that IMO examples rather
>     cloud the view
>      >> - my primary interest is to replace rdf:Lists with
>     rdf:Collections and being able to close is what differentiates them
>     on the semantic level
>      >> But if you insist:
>      >> - a list of my three favorite colors, unordered but finite.
>      >
>      > Not a list, so why try to make a list out of it?
>      >
>      >> - tables made from lists where it is important that each list
>     (table row) has the same length
>      >
>      > If they are not the same length in the original set of triples,
>     then you have to truncate them somehow.  If they are the same
>     length, then you don't need to do anything special.  Either way, I
>     don't see this as anything that needs list characteristics.  The
>     list-ness of the data has nothing to do with how you fill a table
>     with it.
>      >
>      >> And the application that I have always in mind is the
>     contextualizing integrate-all-the-things that will finally bring
>     love, peace and understanding to the world, ahem. But lists don’t
>     play a very prominent role in that.
>      >> Hope that helps
>      >> Thomas
>      >
>      >
> 
>     -- 
>     Hugh
>     023 8061 5652
> 
>

Received on Wednesday, 10 June 2020 19:45:23 UTC