- From: Drew McDermott <drew.mcdermott@yale.edu>
- Date: Fri, 10 Oct 2003 11:56:12 -0400 (EDT)
- 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 representations. 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