[
Lists Home |
Date Index |
Thread Index
]
Simon St.Laurent wrote:
> jonathan@openhealth.org (Jonathan Borden) writes:
> >When I think about ontologies I hardly think about processing at all.
> >How exactly do ontologies intrude into your choices about processing?
>
> I see the meaning of markup as coming from the reader, whether that
> reader is a human or a computer process. Ontologies strike me as a
> deliberate effort to enforce a particular set of meanings across
> processing contexts, so in that sense they affect the possibilities I
> had open in my processing.
>
Fair enough. For certain, some types of writing are meant to be interpreted
primarily if not completely by the reader, for example poetry. Other types
of writing are meant to be interpreted exactly by the reader as written by
the author, for example: a medical prescription. Other documents are
intended to fall somewhere in between.
Ontologies _are_ an effort to proscribe a deliberate _set of meanings_ (as
you write, this is spot on) between the reader and writer (i.e. across
processing contexts if you wish to use this language). I hope you will allow
that there are certain tasks for which it is essential that the reader and
writer share a common understanding of the document (e.g. medical
documentation).
> Beyond that, expectations that processing will be flexible enough to
> handle changes in ontologies requires writing the processing in a very
> different style, requiring my code to understand the ontologies rather
> than just the markup.
>
> It may be declarative, but its impact reaches to the core of the code.
Ah, you expect your code to handle potential changes in the way the "world"
is constructed! An admirable goal, but one not obtained by any software I
know of. I certainly know little "code" that actually understands any
extensive ontology I've seen -- perhaps we can start enrolling PCs in
medical school in the next few years :-)))
...
>
> Thanks, but I don't need or want those burdens. It's not black magic -
> it's merely naive faith in the coherence of logical constructions built
> in a certain way of supposedly atomic facts. I don't trust the premise,
> and I don't want the tools.
>
> Markup's premises are a lot smaller, far easier to comprehend, and
> involve a lot less sleight of hand.
>
Of course that is entirely true.
It comes down to what you are trying to do. For certain tasks, such as those
I frequently give examples of, dealing with markup _alone_ doesn't solve the
entire problem. It's not helpful to me if you criticize a solution to a
problem, without explaining an alternate solution. It's sort of like
complaining that modern CPUs have too many transistors ... it may indeed be
true, and it may be a noble goal of the computer industry to reduce the
complexity of the next generation of CPUs, but for a guy that wants to
transfer copies of DVs of his kids to a DVD, I really don't friggin' care
about much except how much time I am sitting in front of the screen waiting
for this task to get completed.
So please, if you are going to off hand dismiss my solutions, the least you
can do is to try to understand the problems I am trying to solve. "Don't do
that" doesn't quite cut it.
Jonathan
|
