W3C home > Mailing lists > Public > www-archive@w3.org > December 2001

RE: WebOnt General Requirements Subgroup - Initial E-mail

From: Smith, Ned <ned.smith@intel.com>
Date: Mon, 10 Dec 2001 15:01:37 -0800
Message-ID: <0DCC27458EB5D51181840002A507069E0C316B@orsmsx117.jf.intel.com>
To: "'Dan Connolly'" <connolly@w3.org>, Pat Hayes <phayes@ai.uwf.edu>
Cc: Jeff Heflin <heflin@cse.lehigh.edu>, Deborah McGuinness<dlm@ksl.stanford.edu>, "Smith, Ned" <ned.smith@intel.com>, jeremy_carroll@hp.com, jos.deroo.jd@belgium.agfa.com, herman.ter.horst@philips.com, hendler@cs.umd.edu, www-archive@w3.org
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

My comments inserted below.

Ned M. Smith
Intel Architecture Labs          Phone: 503.264.2692
2111 N.E. 25th Ave               Fax: 503.264.6225
Hillsoboro OR. 97124            mailto:ned.smith@intel.com


> -----Original Message-----
> From: Dan Connolly [mailto:connolly@w3.org]
> Sent: Monday, December 10, 2001 1:20 PM
> To: Pat Hayes
> Cc: Jeff Heflin; Deborah McGuinness; ned.smith@intel.com;
> jeremy_carroll@hp.com; jos.deroo.jd@belgium.agfa.com;
> herman.ter.horst@philips.com; hendler@cs.umd.edu;
> www-archive@w3.org Subject: Re: WebOnt General Requirements
> Subgroup - Initial E-mail  
> 
> 
> Pat Hayes wrote:
> > 
> > >Deborah,
> > >
> > >Thanks, your arguments have convinced me. In fact, I now think
> > >the multi-user issues and difference and merging are closely
> > >related to requirements I had listed.
> > >
> > >Everyone, I think it would be helpful if we can try to 
> identify how the
> > >various candidate requirements (original list from Jim, 
> Deborah's list,
> > >my list) are related. Here is my first cut at such a mapping:
> > >
> > >Jeff's                 Deborah's               Original list
> > >-------------------    --------------------   
> > >------------------- shared meaning         multi-user
> > >ontology reuse         extensible
> > >ontology evolution     versioning              versioning
> > >interoperability       diff and merge          domain mapping
> > >inconsistency                                  inconsistency
> > >scalability            scalability             large ontologies

The scalability requirements ought to be sensitive to small
ontologies also (or more precisely, highly granular distributed
ontologies) ala purvasive sensors/actuators and other small devices
that may describe themselves via ontology and be linked to other
devices where the conglomerate is also an ontology. An "ontology web"
or "web of ontologies" has been mentioned on the list. Is scalability
the one word that captures all this?

> > >user-friendly          ease of use
> > >data persistence
> > >                       security
> > >                       XML interfaces
> > >                       internationalization
> > >                                               
> ontology-based search
> > >                                               ontology querying

I see search and query as being distinct capabilities. Search implies
understanding of physical layout of the ontology web. While Query
implies knowledge of the logical structure of the ontology. 

> > >
> > >Although this table only shows Deborah's "multiple users" 
> requirement
> > >mapped to my "shared meaning" requirement, I think it also 
> maps to my
> > >"ontology reuse" and "ontology evolution" requirements.
> > >
> > >Everyone, I'd like you to look at this table and decide if 
> you agree
> > >with my mappings.
> 
> That's a lot of stuff. Do I agree that "security" 
> is a requirement? er... in some form, yes, of course.

My opinion, security is almost always anomalistic and if ignored can
motivate a complete re-design to get it right. The Tim Berners-Lee
layer cake suggests that security is a vertical slice topped with
"trust". 

I find it more effective to think about security as a vertical slice,
that affects every layer, rather than a horizontal layer - which is
tempting to push above or below. The use cases that motivate security
requirements ought to be derived from Edward Felton's work on proof
carrying authorization[1] and other work in distributed trust
management[2].

The question in my mind for WOWG to determine is how should
"SpeaksFor" and "Says" relations be expressed/represented in an
ontology language? The implication being that there is a need to
create ontologies of trust networks and to identify the data
attributes that are trust worthy (having satisfied access control
preconditions). Subtly, this implies attributes can carry state and
that there exists some evidence (proof) that the state is an
appropriate state.

[1] A Proof-Carrying Authorization System, Lujo Bauer, Michael A
Schneider, Edward Felton, Princeton University, Tech Report
TR-638-01, April 30, 2001

[2] Moving from Security to Distributed Trust in Ubiquitous Computing
Environments, Lalana Kagal, Tim Finn, Anupam Joshi, University of
Maryland, (to appear) IEEE Computer, December 2001. 

I'm a little concerned that the time schedule won't allow us to
consider these elements carefully enough. I'm also struggling to
understand where an ontology language like DAML+OIL ends and an
ontology like DAML-S begins relative to security and trust.
Regards,
Ned
> 
> I have a couple/three suggestions:
> 
> (1) make sure the requirements are testable.
> 
> how do you do that?
> 
> (2) make sure the requirements are connected to
> use cases, so that if we don't meet requirement R6,
> it's clear that we won't be able to deal
> with use cases UC4 and UC7, say.
> 
> and how do we do all that with so little time?
> 
> (3) shoot for the intersection of everybody's requirements,
> not the union. Shoot for things that *the group*
> will agree are requirements; i.e. things that
> if our language doesn't meet them, the group will
> agree that we're not done.
> 
> 
> If we end up with things that seem important
> but aren't really agreed as requirements, I'd
> suggest listing them as goals or something.
> 
> 
> Coming back from the meta-discussion...
> 
> 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.
> 
> 
> -- 
> Dan Connolly, W3C http://www.w3.org/People/Connolly/
> 

-----BEGIN PGP SIGNATURE-----
Version: PGP 6.5.3

iQA/AwUBPBU+0RdTablCCzU/EQLQqwCfa5+tQG/YRTfDacZZsGqW+fRe6VIAoJRb
GuFjZjfPrd2mZu0Ma7fcw+XK
=L4G0
-----END PGP SIGNATURE-----
Received on Monday, 10 December 2001 18:01:49 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 7 November 2012 14:17:15 GMT