RE: WebOnt General Requirements Subgroup - Initial E-mail

Ned M. Smith
> -----Original Message-----
> From: Pat Hayes [mailto:phayes@ai.uwf.edu]
> Sent: Monday, December 10, 2001 3:50 PM
> To: Smith, Ned
> Cc: 'Dan Connolly'; Pat Hayes; Jeff Heflin; Deborah McGuinness;
> 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
> 
> 
> >-----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.
> 
> Is, or is connected via ? The idea that a conglomerate of devices IS 
> an ontology is an interesting and (to me) novel idea.

Consider an HVAC (heating, ventalation & air conditioning) system comprised
of a thermostat, furnace and chiller. Each device may be composed of
sub-devices (which I won't describe) and the conglomerate of devices forms
an autonomous HVAC system which in turn might interact with other building
or factory automation. 

I may have a superficial understanding of what constitutes an ontology in
the DAML+OIL sence, but the structure of thermostat/furnace/chiller has an
ontological description. The challenges appear when trying to model the real
world of devices where innovative engineers may decide an HVAC system can
include solar panels, heat pumps or something completely new. Where does the
authoritative HVAC Class definition reside? Is it in the instance in my
building or in the mythical union of all buildings' HVAC systems?

It is the case that many suppliers produce thermostats/furnaces/chillers
that could constitute any particular HVAC system. Industry groups form
standards enabling interchangable parts, but vendors' often differentiate by
extending the standard. How might ontologies make management of proprietary
extensions easier? Interoperability?

If a customer replaces a furnace with a newer model, would there be a
history of the previous model (just in case things didn't work and we had to
rollback to the previous model)? (what if there were multiple furnai(sp?))

It is counter-productive to build a "test network" to do interoperability
testing before replacing a failed component. We expect the replacement to
function properly in the "live" network. Can the ontology help prevent
dangerous configurations / proprietary extensions?

These considerations suggest to me that the conglomerate IS the ontology.
This perspective would not REQUIRE the ontology be replicated on a single
host somewhere. Nor does it suggest that an authoritative image is required
to commission new (smart?) devices. 
> 
> >An "ontology web"
> >or "web of ontologies" has been mentioned on the list. Is scalability
> >the one word that captures all this?
> 
> Yes, I wonder quite what 'scalability' is supposed to mean. Maybe an 
> example of something that isn't scaleable would be helpful (?)

If a network of light switches and toasters is described by an ontology and
by adding one more toaster the other switches & toasters cease functioning
or are unable to talk to the new toaster. Scalability might mean there are
no practical limits to size and complexity of the ontology.

If a replication of the switches/toasters ontology exists on a PC and a
toaster T forgets (reset button?) its ontological description and the
replicated image (ontology) of toaster T no longer fits on toaster T ala
management operations to reconfigure. Then the replication process changed
the image - it may have been semantically equivalent, but some information
was lost. Scalability might mean optimizations for query or interoperability
implies non-lossy reverse transformation is possible.

Variation on above scenario: if toaster T1 forgets its ontology, but toaster
T2 has preserved a copy of T1's ontology and T1 is unable to get T2 to
re-configure T1 then we could say the ontology introspection does not scale.

If a switch can be used to turn on 5 toasters at the same time, but adding a
sixth toaster causes the five toasters to turn on at different times or not
at all then scalability might mean the ability to represent performance
guarantees and be able to define/apply it as a group attribute. We could say
scalability is sensitive to performance expectations.

If by removing the hardware aspects of these examples and think strickly in
terms of ontological flexibility - then some interesting requirements might
be more clear. 
> >
> >>  > >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.
> 
> Ah, that is a different sense of 'search' than the one I was 
> understanding. We need to distinguish between searching-1 the web for 
> relevant content, and searching-2 for valid inferences from a given 
> ontology (one that has maybe been constructed as a result of a 
> searching-1 process, for example.)
> 
> >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.
> 
> I agree entirely. For example, without some security at the lowest 
> transfer-protocol level, one is dead in the water. This seems so 
> obvious that I have always assumed that Tim's cake-top was meant to 
> denote something like 'reasoning about trust' rather than 'functional 
> security', and to refer to the no doubt rather arcane inferences that 
> an agent might use to conclude trustworthiness, rather than to the 
> low-level machinery of secure information transfer and so on.
> 
> >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].
> 
> Again, I agree this work is relevant.
> 
> >
> >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.
> 
> For what its worth, there is some ongoing work (not yet published) on 
> applying DAML+OIL to reasoning about software agent 
> actions/permissions/obligations which several of the participants 
> here are involved with, I believe.
> 
> >
> >[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.
> 
> I would urge that the basic picture should be that access to the 
> content expressed in the DAML+OIL is the primary resource that needs 
> to be made secure, since that access would enable any 'higher' 
> information about trust issues to be tampered with. In other words, 
> it cannot possibly be sufficient to have an insecure ontology of 
> security, since that cannot guarantee any security over content.
> 
> Pat
> 
> 
> -- 
> ---------------------------------------------------------------------
> IHMC					(850)434 8903   home
> 40 South Alcaniz St.			(850)202 4416   office
> Pensacola,  FL 32501			(850)202 4440   fax
> phayes@ai.uwf.edu 
> http://www.coginst.uwf.edu/~phayes
>

Received on Monday, 10 December 2001 22:24:32 UTC