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.

Jeremy



> -----Original Message-----
> From: [email protected] [mailto:topbraid-composer-
> [email protected]] On Behalf Of Bohms, H.M. (Michel)
> Sent: Friday, March 13, 2009 11:58 AM
> To: [email protected]
> Subject: [tbc-users] Re: 'Order' in OWL?
> 
> 
> 
> Jeremy, also thanks (saw your mail later in the stack..)
> 
> I'll have a look on your paper too.
> 
> THx! Michel
> 
> 
> -----Original Message-----
> From: [email protected]
> [mailto:[email protected]] On Behalf Of Jeremy
> Carroll
> Sent: 12 March 2009 21:19
> To: [email protected]
> Subject: [tbc-users] Re: 'Order' in OWL?
> 
> 
> 
> Apologies for a certain 'been there, done that' but ...
> 
> http://lists.w3.org/Archives/Public/www-archive/2002Apr/att-0019/contain
> ers.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: [email protected]
> > [mailto:topbraid-composer- [email protected]] On Behalf Of Holger
> 
> > Knublauch
> > Sent: Thursday, March 12, 2009 9:07 AM
> > To: [email protected]
> > Subject: [tbc-users] Re: 'Order' in OWL?
> >
> >
> > 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
> >
> >
> > On Mar 12, 2009, at 2:30 AM, Michel Bohms wrote:
> >
> > >
> > > 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
> > > >
> >
> >
> >
> 
> 
> 
> This e-mail and its contents are subject to the DISCLAIMER at
> http://www.tno.nl/disclaimer/email.html
> 
> 
> 


--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups 
"TopBraid Composer Users" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to 
[email protected]
For more options, visit this group at 
http://groups.google.com/group/topbraid-composer-users?hl=en
-~----------~----~----~----~------~----~------~--~---

Reply via email to