W3C home > Mailing lists > Public > www-ws@w3.org > October 2003

Parameter puzzlement

From: Drew McDermott <drew.mcdermott@yale.edu>
Date: Fri, 10 Oct 2003 11:56:12 -0400 (EDT)
Message-Id: <200310101556.h9AFuCH23941@pantheon-po03.its.yale.edu>
To: www-ws@w3.org

[I'm reposting this to www-ws, although at this point I'm really
repeating what Mark Burstein said.]

I'm sorry to be so obtuse, but I still don't get Bijan's argument:

   One point I think I failed to actually write out is the rationale for 
   the double levels.

   You can't really put the value on the Input itself because there'd be 
   no way to distinguish *which* value you  were talking about in what 
   context. There has to be some metadata on the value.

   If Inputs were classes, then it would work to have the value straight 
   on. I.e., Input instances would *be* those trace level inputs 

Here is his example, expressed in some kind of bastardized predicate
calculus (please skip to the three triples at the end if you prefer
the original notation):

(subclass AirportInput Input)

(forall (x v)
   (if (and (rdf:type x AirportInput)
            (parameterValue x v))
       (rdf:type v AirportInputValueSpec)))

(subclass AirportInputValueSpec ParameterValueSpec)

(forall (y x)
   (if (and (rdf:type y AirportInputValueSpec)
	    (actualParameterValue y x))
       (rdf:type x Airport)))

(rdf:type departureAirport_In  AirportInput)

// So departureAirport_In is an individual input parameter.  But it
;; will have different values in different execution traces.

(parameterValue departureAirport_In ivs1)

(rdf:type ivs1 AirportInputValueSpec)

(actualParameterValue ivs1 Logan)

It's that last pair of assertions that does me in.  I just don't
understand what the symbols mean well enough to get a clear picture of
what's being asserted.  We have some kind of route from the parameter
to Logan:

    departureAirport_In ---- [ ivs1 ? ] ----> Logan

But all this can possibly mean is that Logan is a legal value for the
parameter.  Even if 'ivs1' is supposed to connote the value on a
particular execution trace, the fact that we don't ever mention the
execution trace means that the relationship between
'departureAirport_In' and 'Logan' is 

     ivs1 is a possible (placeholder for the ?) value of
         departureAirport_In on some execution trace
     Logan is a the actualValue of ivs1 in that trace

But this is just a long-winded way of saying that Logan is a possible
value of 'departureAirport_In'.  What else can I glean from it?  

I'm sure I'm missing something.   Maybe Bijan sees parameterValue as
the vanguard of a whole vocabulary for describing execution traces.
For instance, there might be a way of saying that two InputValueSpecs
are from the _same_ execution trace, in which case we could begin to
infer, for instance, that on this trace departurePassenger_In Parsia
went from departureAirport_In Logan to arrivalAirport_Out BWI.

Please enlighten.

                                             -- Drew
Received on Friday, 10 October 2003 12:03:59 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:37:10 UTC