ontolog-forum
[Top] [All Lists]

Re: [ontolog-forum] Architectural considerations in Ontology Development

To: "'[ontolog-forum] '" <ontolog-forum@xxxxxxxxxxxxxxxx>
From: "Matthew West" <dr.matthew.west@xxxxxxxxx>
Date: Tue, 19 Feb 2013 13:15:51 -0000
Message-id: <51237b05.c462b40a.45f2.0cc7@xxxxxxxxxxxxx>
Dear Paul,    (01)

Sorry, I was too cryptic.    (02)

Double entry book-keeping is an approach to accounting that deliberately made 
more work so that you had what were effectively check-sums so that you could 
quickly detect errors in the accounts from human processed arithmetic.    (03)

Now one of the things that I do trust computers to do is add up accurately, so 
there is no longer any reason to perform double entry book keeping, yet we 
still do it seems. A classic case of computerizing a manual method when it 
would be much more suitable to re-engineer the way accounting has been done.    (04)

Regards    (05)

Matthew West                            
Information  Junction
Tel: +44 1489 880185
Mobile: +44 750 3385279
Skype: dr.matthew.west
matthew.west@xxxxxxxxxxxxxxxxxxxxxxxxx
http://www.informationjunction.co.uk/
http://www.matthew-west.org.uk/    (06)

This email originates from Information Junction Ltd. Registered in England and 
Wales No. 6632177.
Registered office: 2 Brookside, Meadow Way, Letchworth Garden City, 
Hertfordshire, SG6 3JE.    (07)




> -----Original Message-----
> From: ontolog-forum-bounces@xxxxxxxxxxxxxxxx [mailto:ontolog-forum-
> bounces@xxxxxxxxxxxxxxxx] On Behalf Of Paul Tyson
> Sent: 17 February 2013 22:35
> To: [ontolog-forum]
> Subject: Re: [ontolog-forum] Architectural considerations in Ontology
> Development
> 
> On Sat, 2013-02-16 at 14:48 +0000, Matthew West wrote:
> > Dear Paul,
> > So why do you think we still have double entry book keeping?
> >
> 
> Matthew,
> 
> I did not mean to imply that no pre-computer process was suitable for
> computerization. Accounting is not my field, but my sense is that many of the
> pencil-and-paper practices of that domain go directly over into software with
> no loss of meaning and great gains in accuracy and productivity.
> 
> Not so with the domains of activity that have shaped my career: document
> management and product data management. I think these fields were poorly
> served by the first generations of software developed for them because the
> applications were designed around the means of those processes (stringing
> words together on paper and inking lines on mylar) rather than the ends
> (communicating ideas from one person's mind to another's).
> 
> So although we are several decades and software generations into the era of
> distributed computing, those problems are still confronting us. Just this
> month I witnessed a major ERP system go-live, the design of which is replete
> with vestigial features that reduplicate pre-computer means of activities that
> should have been obsolete long ago.
> 
> Regards,
> --Paul
> 
> > Regards
> >
> > Matthew West
> > Information  Junction
> > Tel: +44 1489 880185
> > Mobile: +44 750 3385279
> > Skype: dr.matthew.west
> > matthew.west@xxxxxxxxxxxxxxxxxxxxxxxxx
> > http://www.informationjunction.co.uk/
> > http://www.matthew-west.org.uk/
> >
> > This email originates from Information Junction Ltd. Registered in
> England
> > and Wales No. 6632177.
> > Registered office: 2 Brookside, Meadow Way, Letchworth Garden City,
> > Hertfordshire, SG6 3JE.
> >
> >
> >
> >
> > > -----Original Message-----
> > > From: ontolog-forum-bounces@xxxxxxxxxxxxxxxx [mailto:ontolog-forum-
> > > bounces@xxxxxxxxxxxxxxxx] On Behalf Of Paul Tyson
> > > Sent: 16 February 2013 02:14
> > > To: [ontolog-forum]
> > > Subject: Re: [ontolog-forum] Architectural considerations in
> Ontology
> > > Development
> > >
> > > On Fri, 2013-02-15 at 18:55 -0500, Barkmeyer, Edward J wrote:
> > > > Paul Tyson wrote:
> > > >
> > > > >  I don't know the history of computer graphics applications, but
> > > > > something similar must have happened--the early developers
> looked at
> > > > > draftsmen putting lines and curves on mylar and decided to write
> a
> > > > > program to put lines and curves on a CRT. It's taken several
> > > > > generations of graphics software (each having to "interoperate"
> with
> > > > > the previous generation) to really begin to augment the
> engineer's
> > > > > primary goal of communicating design intent--and some people
> still
> > > > > don't believe that's possible without honoring the conventions
> of
> > antique
> > > draftsmanship.
> > > >
> > > > Well, part of the problem was to get an effective computational
> > > > representation of solid geometry, and the tools that did that
> began to
> > > > emerge after academic feasibility demonstrations in the mid 1980s.
> > > >  And part of that feasibility was having fast enough processors,
> > > > accurate arithmetic, and fine enough graphical resolution and fast
> > > > enough graphics refresh.  That is, a mere 4 or 5 technologies were
> > > > needed to enable that.
> > >
> > > I'm not sure I buy all of that, since there are examples of system
> designs
> > > that outstrip available technology or outpace current requirements
> in
> > > passionate pursuit of a goal: some of da Vinci's machines, Knuth's
> TeX
> > > typesetting system, and sendmail come to mind.
> > >
> > > More to the point of this forum and thread: when (if ever) is it OK
> to
> > merely
> > > "pave over the cow path" by reimplementing concepts, conventions,
> and
> > methods,
> > > largely unchanged, from pre-computer processes into computer
> systems? Did
> > the
> > > early graphics application developers really say to themselves:
> "Look, we
> > know
> > > that these engineers actually need to communicate all the essential
> > physical,
> > > functional, and process characteristics of their designs, but that's
> way
> > more
> > > than we know how to do at this time. Currently they get by with
> inked
> > lines on
> > > mylar, notes and callouts, and parts lists. We can do that much
> > > electronically, so let's go for it!"
> > >
> > > And then the designers of the Nth generation of the software have to
> > decide
> > > (assuming they even have some awareness of the problem) whether or
> not to
> > put
> > > yet another layer of asphalt on the cow path to preserve vestigial
> > features
> > > from an initial choice to render into software what should never
> have been
> > > there in the first place.
> > >
> > > >
> > > > BTW, putting accurate lines and curves on a CRT from a digital
> source,
> > > > rather than an analog recording, was no small feat in 1970, when
> the
> > > > early graphical CRTs first appeared (at significant cost).  As
> late as
> > > >  1990 the cost of top of the line graphics terminals was in the
> 30K$
> > > > range, and had been since the first ones 20 years earlier, which
> is a
> > > > big difference in constant dollars, and had a big impact on the
> size
> > > > of the potential market.  The Tektronix folk made the
> > > > price/performance breakthrough about 1974, and dominated the
> market
> > > > for 10 years until cheap raster technology emerged that could
> > > > approximate the accuracy of their technology.
> > > >
> > > > And for the record, the antique draftsmanship conventions have a
> > > > different motivation -- long-term archival of the engineering
> models.
> > > >  What CAD form from 1985 can still be processed?  Do you think all
> > > > those 1985 aircraft have been junked?  Do refineries built in the
> > > > 1980s still function?  If we now commit to saving the latest and
> > > > greatest Pro-Engineer solid models in native form, what tools will
> be
> > > > able to read the recording media and decode the model and display
> the
> > > > holographic images in 2025, let alone 2050?  If you are
> authorizing
> > > > the construction of a nuclear plant, what archival form of the
> > > > engineering models are you going to require?  Maybe those antique
> > > > draftsmen still have a value.
> > >
> > > There's probably no bigger fan (except you, perhaps) of fine
> engineering
> > > draftsmanship in this forum than me. I'm intrigued by the processes
> of
> > > recording and communicating the design of complex products, and I
> think
> > the
> > > engineering and architectural drafting practices of the 20th century
> > brought
> > > this to a high art. I also think those practices were translated
> into
> > > suboptimal computer systems for achieving the same goals,
> notwithstanding
> > some
> > > obvious local gains in productivity and precision.
> > > One troublesome symptom of the suboptimization is the archiving
> problem,
> > so
> > > that 40+ years into the era we still fall back to 2d drafting
> > representations
> > > for long-term storage. (Of course, the reluctance of CAD vendors to
> fully
> > > support common standards for product model representation is much to
> blame
> > for
> > > this also. See my point 6 in previous post.)
> > >
> > > Regards,
> > > --Paul
> > >
> > > >
> > > > I agree with Paul's sentiment, but the business of engineering
> models
> > > > is important, it is very high tech, and it is fraught with all
> kinds
> > > > of very real business constraints.
> > > >
> > > > -Ed
> > > >
> > > > --
> > > > Edward J. Barkmeyer                     Email: edbark@xxxxxxxx
> > > > National Institute of Standards & Technology Systems Integration
> > > > Division
> > > > 100 Bureau Drive, Stop 8263             Work:   +1 301-975-3528
> > > > Gaithersburg, MD 20899-8263             Mobile: +1 240-672-5800
> > > >
> > > > "The opinions expressed above do not reflect consensus of NIST,
> and
> > > > have not been reviewed by any Government authority."
> > > >
> > > >
> > > >
> > > >
> > > > _________________________________________________________________
> > > > Message Archives: http://ontolog.cim3.net/forum/ontolog-forum/
> > > > Config Subscr:
> http://ontolog.cim3.net/mailman/listinfo/ontolog-forum/
> > > > Unsubscribe: mailto:ontolog-forum-leave@xxxxxxxxxxxxxxxx
> > > > Shared Files: http://ontolog.cim3.net/file/ Community Wiki:
> > > > http://ontolog.cim3.net/wiki/ To join:
> > > > http://ontolog.cim3.net/cgi-bin/wiki.pl?WikiHomePage#nid1J
> > > >
> > >
> > >
> > > _________________________________________________________________
> > > Message Archives: http://ontolog.cim3.net/forum/ontolog-forum/
> > > Config Subscr:
> http://ontolog.cim3.net/mailman/listinfo/ontolog-forum/
> > > Unsubscribe: mailto:ontolog-forum-leave@xxxxxxxxxxxxxxxx
> > > Shared Files: http://ontolog.cim3.net/file/ Community Wiki:
> > > http://ontolog.cim3.net/wiki/ To join: http://ontolog.cim3.net/cgi-
> > > bin/wiki.pl?WikiHomePage#nid1J
> > >
> >
> >
> > _________________________________________________________________
> > Message Archives: http://ontolog.cim3.net/forum/ontolog-forum/
> > Config Subscr:
> http://ontolog.cim3.net/mailman/listinfo/ontolog-forum/
> > Unsubscribe: mailto:ontolog-forum-leave@xxxxxxxxxxxxxxxx
> > Shared Files: http://ontolog.cim3.net/file/ Community Wiki:
> > http://ontolog.cim3.net/wiki/ To join:
> > http://ontolog.cim3.net/cgi-bin/wiki.pl?WikiHomePage#nid1J
> >
> 
> 
> 
> 
> _________________________________________________________________
> Message Archives: http://ontolog.cim3.net/forum/ontolog-forum/
> Config Subscr: http://ontolog.cim3.net/mailman/listinfo/ontolog-forum/
> Unsubscribe: mailto:ontolog-forum-leave@xxxxxxxxxxxxxxxx
> Shared Files: http://ontolog.cim3.net/file/ Community Wiki:
> http://ontolog.cim3.net/wiki/ To join: http://ontolog.cim3.net/cgi-
> bin/wiki.pl?WikiHomePage#nid1J
>     (08)


_________________________________________________________________
Message Archives: http://ontolog.cim3.net/forum/ontolog-forum/  
Config Subscr: http://ontolog.cim3.net/mailman/listinfo/ontolog-forum/  
Unsubscribe: mailto:ontolog-forum-leave@xxxxxxxxxxxxxxxx
Shared Files: http://ontolog.cim3.net/file/
Community Wiki: http://ontolog.cim3.net/wiki/ 
To join: http://ontolog.cim3.net/cgi-bin/wiki.pl?WikiHomePage#nid1J    (09)

<Prev in Thread] Current Thread [Next in Thread>