Re: Requirements Document

From: Jeff Heflin <heflin@cse.lehigh.edu>
Subject: Re: Requirements Document
Date: Thu, 14 Feb 2002 13:23:11 -0500

> Peter,
> 
[...]
> 3) You had a problem with the "Referencing with URIs" requirement. In
> subsequent discussion with Dan, it appears that you would be happy if we
> change the wording to "URIs + frag[]ment ids."
> 
> ACTION: Wording for the requirement will mention "frag[]ment ids."

No, this would not make me happy.  In my discussion with Dan, I stated that
I wanted to be able to refer to anything on the web, and things outside of
the web, as well.  Unfortunately, URIs plus fragments does not get us
there, because XML Schema document definitions cannot be so addressed.

I don't know why this unfortunate state of affairs exists, but the
*requirement* should therefore be, in my mind at least, the ability to
reference what we need to reference, including XML Schema document
definitions.  URIs plus fragments gets us 99% of the way there, and may be
what we end up using, but changing from what we want to a partial solution
for what we want is, in my view, not something that should be done in a
requirements document.

[...]

> 5) You believe the "Ability to state closed worlds" requirement is too
> strong. Once again, this was a requirement that a significant number of
> people think is essential. Obviously, we can't make a closed-world
> assumption, but the ability to infer negative information from the
> absence of positive information is useful. However, I understand your
> concern in that this is not a feature found in existing langauges and
> may be difficult to implement.
> 
> ACTION: We will demote "Ability to state closed worlds" to an objective.
> If anyone wishes to argue for it remaining a requirement, please do so.

It is not just that it is difficult to implement, but that the closure of
a general ontology is not well defined. 

For example, what is the closure of

	John is a Person whose sisters include either Jill or Susan or
	whose brother is Bill.

> 6) You take issue with "At a minimum, the language should recommend to
> users how they can specify their own default mechanisms." If I recall
> correctly, this was a resolution made by the group at a recent telecon
> after considerable debate on defaults.
> 
> ACTION: The requirement will remain unchanged.

Umm, this is an objective, not a requirement, I believe.

If someone can figure out how to ``recommend to users how they can specify
their own default mechanisms'' in a reasonable fashion, I would be very
happy.  However, I don't have a clue as to how to progress towards meeting
this objective.

[...]

> If I missed an important issue, you wanted addressed, please let me
> know. I look forward to fruitful discussions on these topics.
> 
> Jeff

Peter F. Patel-Schneider
Bell Labs Research

Received on Thursday, 14 February 2002 14:03:48 UTC