'Order' in OWL?

[Michel Bohms]

Dear All,

I am currently experimenting with the use of SPIN/Sparql when mapping
one ontology to another.

The source ontology is typically a semantic one (say a Wall class with
height, width and length properties).
The target ontology is typically a less-semantic cad-like explicit
shape representation one (a BoundaryREPresentation (BREP), with
points, lines, faces etc.).

The target ontology is based on existing schema/data structures like
coming from ISO STEP or IAI, initiatives often not yet OWL but other
languages like EXPRESS.

In such other languages it is typically possible to model 'order' like
a Face has 4 ordered Lines: Line1, Line2, Line3, Line4, which when
connected in that order give the boundary of the face.

Now comes my issue: how would I model this 'order' in an OWL-version
of such model? How can I put an order to my taget individuals in my
object properties? In the past I have heard reasons for OWL not
supporting order, being not really a semantic aspect.

All ideas welcome, thx, Michel Bohms

[Arthur Keen]

I have the same issue with keeping topological entities ordered, more
specifically keeping points on a contour ordered. The Jena tutorial
describes RDF containers including "SEQ is an ordered
collection". ...but I am not sure how to do this in TopBraid or even
if this is the right way to do it in OWL.

http://jena.sourceforge.net/tutorial/RDF_API/#ch-Containers

Containers

RDF defines a special kind of resources for representing collections
of things. These resources are called containers. The members of a
container can be either literals or resources. There are three kinds
of container:

* a BAG is an unordered collection
* an ALT is an unordered collection intended to represent
alternatives
* a SEQ is an ordered collection

A container is represented by a resource. That resource will have an
rdf:type property whose value should be one of rdf:Bag, rdf:Alt or
rdf:Seq, or a subclass of one of these, depending on the type of the
container. The first member of the container is the value of the
container's rdf:_1 property; the second member of the container is the
value of the container's rdf:_2 property and so on. The rdf:_nnn
properties are known as the ordinal properties.

[Irene Polikoff]

RDF ordering is pretty ugly. I don't know of anyone using it.

There are two possible uses of ordering:

1. To specify the order of different properties. For example, height before
length

2. To specify the order of different values for the same property

In some situations it will be possible to resolve use case 2 into use case 1
by creating different properties. In Michel's example it would mean creating
Line1, Line2, etc. properties and, possibly, for convenience, making them
all subproperty of Line.

More than one design patterns are possible for the use case 1. If the order
of the properties is always the same irrespective of how they are used, you
can just specify it as annotation on the property by creating a special
annotation property - could be "order" with a numerical value range similar
to the composite:indedx
http://composing-the-semantic-web.blogspot.com/2007/07/composite-design-patt
ern-in-rdfowl.htmlor sequence reference pointing to the next item.

If the order is contextual (for example, for a rectangle height goes before
length, for a trapezoid, length goes before height), the more complex
modeling patterns are needed. One of them is actually implemented in TBC and
you can examine it. Form customization in TBC captures the order of the
properties in the form. You can take a look at .tbc files to understand how
it is done.


Irene Polikoff

[Holger Knublauch]

Yes, order is a common request and an important topic. In addition to
the rdf collections such as rdf:List and rdf:Seq, you can hand-code
ordering by attaching additional triples to the ordered elements. For
example, in those cases where the ordered elements are "owned" by the
parent, you can simply attach an index to each of them, as described
in the Composite Design Pattern [1]. This pattern (based on the
composite ontology described below) is extensively supported by
TopBraid, so that, for example the fields on the forms will be ordered
accordingly. We are also using this pattern for the conversion between
XML and RDF/OWL using Semantic XML.

There may be other solutions, none of them is easy though, because RDF
only has triples...

Holger

[1] http://composing-the-semantic-web.blogspot.com/2007/07/composite-design-pattern-in-rdfowl.html

[Jeremy Carroll]

Apologies for a certain 'been there, done that' but ...

http://lists.w3.org/Archives/Public/www-archive/2002Apr/att-0019/containers.html

Basically the problems were ones that were already apparent in 2001 or so - my suggested fix above, was too clever by half, but if you really want to model order in your application, it is basically still my suggestion.

Look at the pictures - they are better than the text.

Each resource in a grouping is proxied for by a blank node in the grouping, and any ordering or inequality relationships in the grouping are made explicit (ct:notEqual would nowadays be owl:differentFrom).

I expect a limited version of this proposal could easily be encoded in spin rules ...

I think the crux of the issue is:

> In the past I have heard reasons for OWL not
> supporting order, being not really a semantic aspect.

which is true if you do not represent the order as an explicit concept.
If the order is an important part of what you are modeling, then represent it explicitly, use the mathematical theory of orders (it is fairly simple), and you arrive at something not dissimilar to my approach from 2002.

Jeremy

> -----Original Message-----
> From: topbraid-co...@googlegroups.com [mailto:topbraid-composer-
> us...@googlegroups.com] On Behalf Of Holger Knublauch
> Sent: Thursday, March 12, 2009 9:07 AM
> To: topbraid-co...@googlegroups.com
> Subject: [tbc-users] Re: 'Order' in OWL?
>
>

[Bohms, H.M. (Michel)]

Thx Holger & Irene,

Indeed using an index might be the simplest thing (better than I guess a
predefened next and/or previous property).

Furthermore, I consider changing our pmo: hasPart into your child
one...getting extra TBC support for it for free....

I'll experiment a bit, thx Michel

-----Original Message-----
From: topbraid-co...@googlegroups.com
[mailto:topbraid-co...@googlegroups.com] On Behalf Of Holger
Knublauch
Sent: 12 March 2009 17:07
To: topbraid-co...@googlegroups.com
Subject: [tbc-users] Re: 'Order' in OWL?

This e-mail and its contents are subject to the DISCLAIMER at http://www.tno.nl/disclaimer/email.html

[Holger Knublauch]

> Furthermore, I consider changing our pmo: hasPart into your child
> one...getting extra TBC support for it for free....

It is sufficient to create sub-properties of composite:index to get
the ordering benefits of the UI.

Holger

[Bohms, H.M. (Michel)]

Jeremy, also thanks (saw your mail later in the stack..)

I'll have a look on your paper too.

THx! Michel

-----Original Message-----
From: topbraid-co...@googlegroups.com
[mailto:topbraid-co...@googlegroups.com] On Behalf Of Jeremy
Carroll
Sent: 12 March 2009 21:19
To: topbraid-co...@googlegroups.com
Subject: [tbc-users] Re: 'Order' in OWL?

[Jeremy Carroll]

The approach of using an index number as suggested by Holger works well enough most of the time.
It depends what you're doing.

If anyone is old enough to remember programming in systems such as Basic with line numbers, where you would number your lines 100 200 300 etc so as to leave room for 110 120 130 etc
And then 101 102 103
As you debugged .... (I would typically get to this point and have to renumber more extensively).



Holger's indexing is a bit like that I think.
If you know precisely what you want to do, number 1, 2, 3 ...
If you're sort of alright with where you're at, but want some wiggle room then leaving gaps in the index is a better policy.

The approach I argued for is basically harder conceptually - and not worth the effort much of the time.

[Holger Knublauch]

I agree, this is one of the main drawbacks of the indexing approach.

I did start with Basic on C64 myself, but in the old days the line
numbers had to be positive integers. The composite ontology (in
theory) allows the use of floating point numbers, to squeeze 1.5
between 1 and 2. They may have fixed that on the C128 :)

But on a more serious note, it is sometimes possible to find a natural
ordering (e.g. by size), and then have spin:rules that infer the index
values for display purposes. Combined with the statement above, you
could in theory order values by any other (linked) property
expression, as long as it creates a float number.

Holger