Re: Hashing, and Ted's concerns about wastefulness

At 12:59 PM 2/2/99 -0800, Ted Hardie wrote:
>Graham,
>	Thanks for your message; I've snipped extensively in the reply,
>just to keep this from becoming totally unreadable.  My apologies if
>it get's hard to follow.
>
>
>> >I think this is workable, but we will need to be very careful in
presenting
>> >this to ensure that there is no confusion between g.<URI> h.<URI>;
>> 
>> After debating with myself whether this really matters, I agree.
>
>Great.  I think there is a large chance naive users will confuse the
>URI at which a feature is described and the URI at which a list of
>features and their values is given, just because the syntax will
>look so similar.  Anything we can do to make that as clear as possible
>will be useful.

Can you give a concrete example of where someone could conceivably
mis-apply what they obtained on dereferencing such an URI, no matter what
the reference syntax is?

On the one hand (list of features and their values) one is following a
reference which supplies propositions about the current entity.

On the other hand, (tag definition reference) one is following a reference
which supplies propositions about any entity to which a property is applied
in association with this tag.  Including the current entity.

What if the cited document makes it clear whether it states propositions
about <self> or about <tagID>?

There is at least the option to distinguish these things in the [semantics
of the] cited document as opposed to in the citation.  Both of the examples
discussed here are qualifiers which serve to impose a subtype reduction on
the current entity.  Either one introduces new knowledge into the current
context.  What is the difference that must be denoted by syntax?  Assigning
a value may be treated as the ultimate subtype reduction.

Al

>
>
>> 
>> >... we also
>> >need to specify exactly what you get if you retrieve h.<URI>.
>> 
>> I think that what you get is a copy of the hashed feature expression.
>
>Yes, but we need to specify exactly how that is represented.  Remember
>that most hashes on files care about every bit of whitespace and every
>control character; if we don't specify the representation very well,
>we will end up with conflicting hashes on equivalent feature expressions.
>
>
>> In this context, I regard "disagregation" as the process whereby the
>> feature set reference is replaced by the feature set expression;  i.e.
>> dereferencing.
>
>This is what I meant by disagregation; I'll adopt "dereferencing", if
>you prefer. 
>
>
>
>> >...  Send along the hash with the predicates, and
>> >you can use the hash in place of repeating elements without worrying
>> >that the other party won't understand it.
>> 
>> This is easy, and can just about be done with the current spec:  simply
>> carry an auxiliary predicate:
>> 
>>     ( <feature expression using sub-expression (h.<URI>=<hash>) )
>>     WHERE
>>         (h.<URI>) :- ( <expression> )
>>     END
>> 
>> >...  Refer to the hash with a
>> >URI that contains the disaggregated form, and the parties will
>> >sometimes be able to retrieve the disaggregated forms.
>> 
>> That would be the above case, omitting the WHERE clause.
>
>Only if you assume all the steps which are involved in retrieving the
>dereferenced/disaggregated forms.  This is why I don't agree that the
>mechanism of dereferencing/disaggregation can be dealt with *solely*
>on a protocol by protocol basis. Remember that one of the goals of
>this system is that feature information presented in it ought to be
>usable across protocols and through protocol gateways.  If we leave
>the dereferencing/disaggregation step totally within the purview of a
>specific protocol, the http-based ones may well use
>(h.http://www.foo.com/featurepredicates.txt=) where directory
>services based systems might use
>(h.ldap://ldap.server.com/dn=featurepredicates,o=foo,c=us)=<HASH>)
>
>As long as the <HASH> is the same, we don't have a problem. If a
>lookup is needed and the "wrong" url scheme is used, the match fails
>for lack of information.  Inband error reporting and retrieval may fix
>that in some cases, but it remains a concern.  
>

>
>> I don't think the method here is a one size fits all type of solution.  Any
>> given application would need to indicate an appropriate method.  For
>> example:  in WWW, retreive the resource indicated by the URI;   in e-mail
>> use the tag in a directory search or RESCAP (aka MAILCAP) resolution.
>
>I don't want to be tarred with a "one-size" fits all brush here; I
>want, instead, to say we have to make all the suits out of the same
>materials.  That may mean that we say, for example, directory lookups
>for these should be able to key on the <HASH>, rather than only on the
><h.URI>, but we don't specify what directory we use.  
>
>
>> I'd be happy to have a go at the (h.<URI2>="<hash>") proposal, if that
>> doesn't pre-empt anything that Bill is planning.  I would be more
>> comfortable if we had some consensus on scenarios and goals so that it can
>> be seen to address the perceived problem.
>> 
>> #g
>
>Any concrete proposal would be good, and two may well be better at this
>early stage.
>		best regards,
>				Ted Hardie
>