Lists Home |
Date Index |
- From: "Bullard, Claude L (Len)" <email@example.com>
- To: "Simon St.Laurent" <firstname.lastname@example.org>, XML DEV <email@example.com>
- Date: Fri, 22 Dec 2000 10:03:10 -0600
If you inherit an ontological service, you may
be right. If you delegate it, you get to reuse
the delegate for any method that takes an
ontology of that type. Delegates are mortar
that depend on what brick they are bound to
as to the strength of the binding. Choose wisely.
A web that can afford ontologies is
recouping costs of services. Focus on
the service and the domain of the ontology
falls out directly. The content of the
ontology is a harder problem but one which
its users have to solve and will if it makes
a hard job easier.
Anyone who thinks we will turn on machine
processable negotiations for critical business
then not test them and use the results to control them
is smoking dope. The golem serves; it does not rule.
Ekam sat.h, Vipraah bahudhaa vadanti.
Daamyata. Datta. Dayadhvam.h
From: Simon St.Laurent [mailto:firstname.lastname@example.org]
Ontology as mortar fits my argument quite nicely - it's convenient glue for
sticking heavy things together, but it's damn near impossible to reuse
after it has set, has almost no flexibility, and it isn't very good about
changing position, either.
I'd suggest we stay away from masonry altogether in this business. I find
your metaphor more convincing than your argument, at least as far as
ontology is concerned.