W3C home > Mailing lists > Public > www-webont-wg@w3.org > January 2002

Re: defaults

From: Dan Connolly <connolly@w3.org>
Date: 23 Jan 2002 10:09:40 -0600
To: Frank van Harmelen <Frank.van.Harmelen@cs.vu.nl>
Cc: www-webont-wg@w3.org
Message-Id: <1011802180.4874.62.camel@dirk>
For me, defaults are not a requirement.

In fact, I'm opposed to making them a requirement.
I gather collection management is the use case area
that motivates defaults. I do lots of collection
management in RDF and DAML+OIL without defaults, and I've
seen lots of other folks do it without defaults,
so I must be missing something.

Remember: we're not
chartered to solve all the world's problems in OWL 1.0;
we should do the minimum that advances
the state-of-the-art. 0/1/2 cardinality stuff,
domain-dependent range constraints, and
synonym-building stuff would suit me pretty well.
If we build some momentum
around OWL 1.0, we can perhaps use that momentum
to offset the cost of deploying defaults
in our next version.

Meanwhile, I'm in favor of exploring the costs
and benefits of potential solutions while
discussion requirements, so...

On Tue, 2002-01-22 at 14:15, Frank van Harmelen wrote:
> 1/ Michael's proposal will not destroy any semantics we choose to supply
> since, in your own words, it is "outside of the logic underlying OWL".
> Default expressions would be something without a formal semantics,
> but with an informally stated intent/purpose.

Let me see if I understand this proposal: basically,
just like RDFS has rdfs:label and rdfs:comment properties,
we could specify an owl:default (or owl:typicalValue or whatever)
property. It's there, it contributes a fact
to the KB, folks can do vanilla inferencing
based on it, but there's no magic, no
non-monotonic reasoning, etc.

Best case: the implementation/user community comes
to consensus, after we specify this thing, on some
useful understanding of this property. It costs
us basically nothing. Everybody is happy.

Worst case: "implementors [...] do whatever they want and claim that
they are just following the standard"[1], resulting in surprising
mismatches in behaviour of agents, not interoperability.

On balance, I don't think we should take the risk.
Anybody in the community can make their own coolsystem:default
property, explain to the community how it works, sell
the idea, and start to build consensus. (Yes, there's
a risk/cost that this will happen several times, independently,
with differences that aren't interesting. I find
that risk/cost acceptable.) At that point, W3C
should step in and standarize. But not before.

[1] pfps 22 Jan 2002 12:37:13 -0500

> 2/ It will be easy enough to make clear that we are not doing
> anything precise about defaults in whatever pieces we produce
> (be they formal or not)

I am not optimistic about that.

> 3/ it will at least encourage implementors (and ontology constructors) to
> not encode anything silly about defaults in the formal part of the
> language (the point made by Michael's example, I believe). 

Here's a suggestion to address that risk: put a big editorial
NOTE or non-normative appendix in our spec ala:

	We considered defaults, but didn't decide on any particular
	design. If you have a design, we encourage you to experiment
	by making your own "default" property(ies) in your
	own namespace [see examples in the _RDF primer_ for how to
	so that sort of thing...]. Please report your
	implementation/deployment experience,
	including implementation costs/challenges, documentation and
	training issues, etc, to www-rdf-logic@w3.org

It would be really nice to start in that direction by
putting defaults in the "goal, but not requirement" section
of our requirements/use-cases document, citing the implementation
challenges Peter et. al. have pointed out on the one hand,
and the use cases Guus et. al. have pointed out on the other.

Hmm... I wonder if we have an un-stated requirement for
monotonic reasoning? I know monotonicity is a requirement,
for scalability, in my view. I'd like to see that
discussed in the design goals, if not listed as a specific
requirement. (In order to make it a specific requirement,
I should provide a compelling use case that depends
on it. I hope to do so, but I'm not confident I'll  find
time, nor am I confident that we'll want to devote
much space in our document
to that sort of thing; I hope it's sufficiently
clear to folks after a brief design-goal level discussion).

JeffH and requirements editors, please let me know what
you think of this suggestion.

Dan Connolly, W3C http://www.w3.org/People/Connolly/
Received on Wednesday, 23 January 2002 11:09:40 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 23:04:26 UTC