Re: defining the semantics of lists

Op wo 10 jun. 2020 om 21:52 schreef Thomas Passin <tpassin@tompassin.net>:

> 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.
>

Yes, I think that should work. However, it does blow up the data volume
because implicit knowledge (the meaning of the order of list elements) is
made explicit. So there's a certain loss of efficiency.

>
> (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).
>

I am afraid that for geographical data (that's my background) a solution
with explicit length properties might not work. That's because the distance
between two locations may not be known or can not unambiguously be
determined. The earth's surface is not smooth and constantly changing, that
complicates matters.


>
> 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.
>

That is a strong argument.
Still, one thing I notice is that fitting existing list structures and
methodologies in RDF may always be possible, but will incur penalties in
the areas of data volume and (probably) the ease of processing. Those are
somewhat important issues, considering that the subject matter is data on
the web - data that are moving about on the Internet. Couldn't trying to
keep data lean to avoid data traffic congestion and negative environmental
impact count as a pro-list argument?

Regards,
Frans



>
> > 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
> >
>
[snip]