Hashing, and Ted's concerns about wastefulness

At 22:52 29/01/99 PST, Larry Masinter wrote:
>> The lookup problem bothers me, because I believe there will be
>> relatively few cases where the hash as given would be instantly
>> recognizable (since it includes both features and feature values).
>
>   (SONY_VGA_MODELXXX) :-
>      (| (& (pix-x=640)
>            (pix-y=280)
>            (color=256))
>         (& (pix-x=1028)
>            (pix-y=1028)
>            (color=256)))
>is equivalent in this regard to
>   (fh=1aXb124AsDfg) :-
>       (| (& (pix-x=640) ...)
>
>i.e., there's a value that expands to other values, that you
>either know or have to look up. The advantage of "fh" is that
>if Sony's VGA display's features are the same as NEC's, you
>don't need to keep both in the table.

If I understand your approach correctly, you want to have a way of
expressing arbitrary aggregations that does not rely on some registration
mechanism to define its meaning, and also does not say anything about how
unknown aggregates are resolved.

I'd like to make a small counter-proposal to the that incorporates an idea
from Ted, overcomes some issues of compatibility with current syntax, and
still (I believe) achieves your goal:

#   (h.1aXb124AsDfg) :-
#       (| (& (pix-x=640) ...)

(What I have done is replaced the 'fh' tag with 'h.<hash>' as an auxiliary
predicate tag.)

Another approach that also permits some indication of retrieval mechanism:

#   (h.<URI>="<hash>")

within a capability expression (this conforms to current syntax rules),
where <hash> is calculated over the body of a notional auxiliary predicate:

#   (h.<URI>) :- 
#       (| (& (pix-x=640) ...)


[...]
>> So the question for the "fh" possibility is: how and when do we allow
>> for the hash to be disaggregated?
>
>Yes, but it's not so different for any of the other proposals
>for aggregated feature.

I agree.

A key advantage I see to the hash approach is that one has a way to
validate whatever disaggregated value one may have to hand without resort
to externally held reference information.


>> I suppose we can create a feature that is, in fact, a request for fh
>> to be disaggregated.  
>
>I think that's mixing descriptive information and protocol in
>an unfortunate way. I think disaggregation is likely to be
>protocol dependent, even though the semantics of "fh" is
>protocol independent.

Again, I agree.

If two expressions contain the same sub-expression:

#    (h.<hash>
or
#    (h.<URI>="<hash>")

then they are known to match at that point without disaggregation.  OTOH,
if they have different hash values then disaggregation is needed to
determine whether or not they truly match.  No additional "feature" is
required to trigger the disaggregation mechanism;  simply some kind of
"lazy evaluation" component in the feature set matching process.

Further, using my second proposal, two different tags:

#    (h.<URI1>="<hash>")
#    (h.<URI2>="<hash>")

can be assumed to match if the hash values are the same (e.g. for rebadged
versions of the same mobile phone).

An attractive property of this approach is that it can be used with the
current specification (with registration of the 'h.' facet), in many cases
will yield the correct result, and will never yield a false feature set
match.  Agents with additional knowledge can reconcile the apparently
different feature tags (this is also behaviour consistent with the current
specification.)

#g

------------
Graham Klyne
([email protected])