[
Lists Home |
Date Index |
Thread Index
]
8/20/2002 9:46:14 AM, Eric van der Vlist <vdv@dyomedea.com> wrote:
>
>The fact that a language allows to write readable documents doesn't mean
>that any document using this language will be readable :-) and some
>years ago I used to say that one can write a readable and modular
>program in assembly language or an unreadable and non modular one in
>Pascal...
I'm not sure about Simon, but the way I'm thinking of the "human" aspects
here is not so much readability, but ability to deal with error and
ambiguity.
Perhaps RDF can be used as a pattern-matching tool rather than
a logical inferencing system, and maybe "pattern matching" can be logical
as well as heuristic. Still, an astronomical number of electrons
have changed state in search of a definition of URIs that can
support the needs of RDF, and that suggests to me that the notion
of "identity" is profoundly important in the RDF paradigm.
The reason I think these issues are connected is that "identity" is difficult
to get right in systems where humans are involved -- not just as authors
or readers, but as data entry clerks, purchasing agents, committees writing
specs and requirements, managers watching the bottom line and ROI, and so on.
All that puts a lot of "fuzz" in the system ... Which version of the
spec does this URI refer to? What happens if it validates with the
sender's schema processor but not the reciever's? What happens if the
"real" URI is http://www.w3.org/some/thing/or/another but the webmaster
"nicely" set things up so that http://www.w3c.org/some/thing/or/another
is an alias, so the URI checking logic breaks?
My point is that when humans are involved, there are a bazillion ways for
identities to break, and if a system's logic depends entirely on the identities
being correct, it will be fragile. If the logic depends on webs of identity
in metadata, it will probably be even more fragile because (up to now, anyway)
metadata tends to be "metacrap" because it is of less value to the authors,
or less visible in the tools, or whatever.
Of course, there are MANY, MANY occasions where this fragility is a
good tradeoff in return for efficiency, integration with knowledge bases,
integration with machines, and a lack of ambiguity in the results (e.g.,
draconian error handling). My argument is that an approach that is more
ambiguity tolerant, based on patterns in data rather than identity defined
by metadata, can be an attractive alternative when there are fallible humans
around to screw things up.
|
