[...] > About inconsistency... I'm happy with > a requirement that our language should > (a) have the ability to express > inconsistent facts (e.g. using disjoint) > and (b) the specification should have > clear semantics for what's an inconsistency > and what's not, but I don't want to > go as far as (c) that it be straightforward, computationally, > to determine, given any two expressions > in our language, whether they're consistent. > > i.e. the sort of use cases I have in mind > for a requirement about inconsistencies > are, for example, catching common > ontology-design errors (flag empty > classes, flag empty classes that have > things in them ;-), or well-known > errors in the use of some ontology, > like perhaps units mismatches in > a space-ship-parts ontology. > > But I don't have any use cases that > motivate a general decidability requirement. my thoughts *intersect* with that kind of inconsistency requirement I think the examples I gave in http://lists.w3.org/Archives/Public/www-webont-wg/2001Nov/0126.html are *consistent* with that :-) -- Jos De Roo, AGFA http://www.agfa.com/w3c/jdroo/ -- Jos De Roo, AGFA http://www.agfa.com/w3c/jdroo/Received on Monday, 10 December 2001 17:24:13 UTC
This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:31:39 UTC