SUO: RE: RE: CAD "data models", "FOL type stuff" and translators
Dear Mike,
I think I can answer this question:
> > You are correct, however, that there is no abstract, upper
> ontology for the
> > geometry definitions.
>
> I wonder why, and also I wonder WHETHER there would be
> benefit in doing so.
> Some people on this list express views that anything that can
> be formalized
> should be formalized. I disagree. It should if there is
> demonstrable value in
> doing so, or if one has reason to believe there should be,
> and hoping to test
> that hypothesis.
Well firstly I would contend that a data model is an ontology, and with the
ability EXPRESS has to state constraints, not that limited.
However, if we take the formalisation of definitions that we are generally
happy to leave in English, I think the main reason is that the exchange file
is neutral in the sense that it does nto process the data that it put into
it.
If you look at where you need the rules, it is in the applications that
create the geometry in the first place. The rest is largely down to the data
models that underly the implementations, and remebering to add the implicit
information from the systems functionality (how it uses the information).
Regards
Matthew
============================================
Matthew West
Operations & Asset Management
Shell Services International
H3229, Shell Centre, London, SE1 7NA, UK.
Tel: +44 207 934 4490 Fax: 7929
Mobile: +44 7796 336538
E-mail: Matthew.R.West@is.shell.com
http://www.shellservices.com/
============================================
> -----Original Message-----
> From: mfu@redwood.rt.cs.boeing.com
> [mailto:mfu@redwood.rt.cs.boeing.com]
> Sent: 03 November 2000 01:04
> To: WBurkett@pdit.com
> Cc: standard-upper-ontology@ieee.org
> Subject: SUO: RE: CAD "data models", "FOL type stuff" and translators
>
>
>
>
> > (The "said" you cited was actually Matthew West, not Phil
> Jackson, but
> > whatever.)
>
> Oops, thanks for pointting that out...
>
> > I've been involved in the work of TC184/SC4 since 1984 and
> CAD data exchange
> > since 1982 and lived with the issues/concerns that you
> touch on here for
> > what seems like my entire adult life. From this
> perspective, I'd like to
> > comment on a few of your observations:
>
> Well - then we MUST talk! Where do you live/work?
>
> > You are right - the GIS people have been looking into this
> problem for a
> > long time and have a long history as well. What is
> interesting about their
> > work is the "flavor" that permeats their work. They are the only
> > researchers in this area that explicitly address the
> > cognitive/linguistic/social factors involved in "meaning" and
> > "understanding" data. (Which is precisely the drum that I
> keep beating.)
>
> But do we know that understanding and meaning is going to
> help them? Can
> we convince/show them that?
>
> > >Others attempt to build neutral formats, in hopes of addressing
> > > the number of translators being O(n-squared) vs O(n).
> >
> > The problem is actually worse than this. If you consider
> multiplexed
> > relationships among n data sources you get a combinatoric
> explosion of
> > interfaces required. (Multiplexed: Translating data from 2
> data sources
> > into a third is not equivalent to two binary translations
> from each source
> > into the third.)
>
> Very interesting - I had not thpought of that before. Is this really
> a problem in practice? How often and in what kinds of circumstances?
>
> > >This would seem an
> > > obvious place for a 'upper' geometry ontology (UGO), from
> which a standard
> > CAD
> > > format could be specified. What is interesting, is that
> no-one in this
> > area
> > > seems to know or care about 'ontologies'.
> >
> > Not entirely true - there are those like Matthew and myself
> that trying to
> > bridge the gap. :-)
>
> Let's say many many are doing good work in the area, building
> commercial tools
> which do translations all the time, and they seem unaware. No
> doubt there are
> some that DO know and care. Florence Tissot at KBSI is one. She built
> trnaslators for IDEF tools at one time.
>
> > >I have an impression that the neutral formats in this
> area, in some cases,
> > are not so much
> > > carefully thought out rationalized models of the domain,
> but rather more
> > like
> > > 'representational dumpsters' which have one of everything.
> >
> > This is not really true in the CAD data exchange world. Speaking
> > specifically of ISO 10303-42 ("CAD" geometry), the representation of
> > geometry is very well thought-out and is based on CAD
> geometry data exchange
> > experience dating back the 70's. It has a small number of
> representations
> > that are very concrete, unambiguous, and relatively free
> from numeric
> > inaccuracies that are caused by ASCII representation of numbers.
>
> I commit a gross error of oveer-generalizing... What I should
> have said is at
> least *one* neutral format seemed to have this dumpster
> characteristic. I had a
> long chat over dinner with the representative from a startup
> company trying to
> break in to the CAD translation business. I wonder how many
> other neutral
> formats have this character?
>
> In the CAD world, there is a lot of translation that goes on
> which result in
> 'dead' geometry. That is to say, in the target tool, you can
> look at it, but
> not edit it. You just get raw geometry. This particularly
> true for STEP APs.
> The better products are now targeted at retaining some of
> this, so that as much
> as possible, the translated geometry in the target system is
> just like it was
> authored by an expert in that system. This is HARD, of
> course, and impossible
> to fully automate, in general. But much can be automated.
>
> > You are correct, however, that there is no abstract, upper
> ontology for the
> > geometry definitions.
>
> I wonder why, and also I wonder WHETHER there would be
> benefit in doing so.
> Some people on this list express views that anything that can
> be formalized
> should be formalized. I disagree. It should if there is
> demonstrable value in
> doing so, or if one has reason to believe there should be,
> and hoping to test
> that hypothesis.
>
> > > This is probably slightly off the topic of SUO, but if
> there are any folk
> > who
> > > have this as a core interest, and would like to have a
> discussion, please
> > let
> > > me know who you are. I will collect names and respond
> back in time. I
> > suggest
> > > that you email ME only, not the SUO group, there is
> already far too much
> > > volume...
>
> > Please include me and I apologize for adding to the volume.
>
> well, i dont suppose it is any more off topic that a lot of
> other things
> on this list... Let's see if anyone complains ;-).
>
> mike
>