Lists Home |
Date Index |
Danny Ayers wrote:
>>email@example.com (Mike Champion) writes:
>>>The best is the enemy of the good.
>>In the case of DOM, the twisted semi-generic mess was the enemy of the
>>Nor does that epigram push strongly against my conclusion, which
>>includes a range - the further you get from the syntax, the deeper the
> The epigram's ok as far as it goes, but I disagree with the poison tasting.
> The cases mentioned (XPath etc) do suggest that distance from syntax is
> proportional to toxicity, *but* all these cases have one-size-fits-all
> semantics. Closer to the syntax (as in DOM), the model and a particular
> (abstract) syntax are tightly bound, even equivalent.
> But meaningful communication depends on some level of shared semantics. So
> ideally we should perhaps be looking at looser coupling between syntax and
> semantics. It shouldn't be necessary to buy into a whole package of meaning
> (a company's invoice structure) but be able to map selectively between local
> models in a global environment, choosing the syntax that best fits. The use
> of purpose-specific XML languages has an implicit alignment to the
> single-model approach, and that I think is where the problem lies. The model
> is the baby, the syntax merely the bathwater.
> I personally think using an uber-framework about syntax and
> business-specific models is the only way around this, and the RDF/OWL
> approach seems a very good candidate.
John Sowa just posted this on the Conceptual Graph list -
In it he refers to another article, and says in part -
"I like his examples of companies that have no definition -- or
sometimes, too many definitions -- of fundamental terms, such as
"customer" and "product". Trying to define a "standard ontology"
that would state official definitions of such terms would not help.
On the contrary, it might make matters worse:
1. If there were an official definition, some programmer or
database administrator might be tempted to implement it.
2. As a result, every application that assumed a different
definition would fail.
3. In an ideal world, programs would stop with an error message
that explained that there was an incompatible definition of
some critical term.
4. In the real world, most programs would continue to run, but
they would generate erroneous data that might cause important
customers or products to be ignored or treated incorrectly.
5. Even if all offending definitions could be found and
eliminated, programmers might be forced to implement
"work-arounds" consisting of highly insecure and illegal
code to handle customers and products that fall outside
the official definitions. "