Dear Paul,
So why do you think we still have double entry book keeping? (01)
Regards (02)
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/ (03)
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. (04)
> -----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
> (05)
_________________________________________________________________
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 (06)
|