Subject: Re: Distinguishing features and feature sets

From: Graham Klyne <[email-masked]>
Date: Wed, 03 Feb 1999 14:11:03 +0000

At 20:46 02/02/99 -0500, Al Gilman wrote:
[...]
>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?

Let me try.  Suppose that:
    'g.http:foo' is a tag that identifies some specific feature.
and
    'h.http:bar' is a tag that identifies some feature set.

Within a feature predicate, the expression:
    (g.http:foo="abcdef")
will match another conjunction that:
(a) also contains exactly (g.http:foo="abcdef"), or
(b) does not contain any reference to 'g.http:foo'.

OTOH, an expresion containing:
    (h.http:bar="abcdef")
matches another conjunction that:
(a) also contains exactly (h.http:bar="abcdef"), or
(b) contains some other feature set reference (h.http:caz="abcdef"), or
(c) matches the original expression with '(h.http:bar="abcdef")' replaced
by the dereferenced value of 'h.http:bar'.

Fundamentally, there is a type difference between 'g.http:foo' and
'h.http:bar', and they have different matching rules.

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

If I understand you correctly, the problem here is that we wish to be able
to complete feature set matching without always having to access the cited
"document" (or feature definition).  So we are looking for some indication
of the difference at the point of reference.

>There is at least the option to distinguish these things in the [semantics
>of the] cited document as opposed to in the citation.

See above.

>  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.

Again if I am understanding you correctly, I think the issue is here is the
extent of new knowledge that is introduced.  In some cases it is sufficient
for both sender and recipient to know that the capabilities of a
(SONY-GIZMO) device are asserted;  in other cases, if (ACME-COMMUNICATOR)
is a rebadged (SONY-GIZMO) they use their own name but indicating the same
feature set (hence the same hash value), so the features known as
(ACME-COMMUNICATOR) can be konown to match (SONY-GIZMO) without knowing the
actual features;  in other cases it will be necessary to actually recover
the feature set to determine a match.

#g

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

---

From: Al Gilman <[email-masked]>
Date: Wed, 03 Feb 1999 12:56:57 -0500

At 02:11 PM 2/3/99 +0000, Graham Klyne wrote:
[...]
>the feature set to determine a match.
[hope that's enough summary]

The lazy client that doesn't want to dereference ACME-COMMUNICATOR will
match it with ACME-COMMUNICATOR and treat ACME-COMMUNICATOR and SONY-GIZMO
as values of different tags.  The industrious client will dereference
ACME-COMMUNICATOR and know it matches SONY-GIZMO or the content of SONY-GIZMO.
Yes?

I guess I just missed an earlier turn in the road -- like the motivation
for hashes.
I am not sure you should be messing with hashes.  Use

h.True where URN

for feature sets and make sure that the sets are cleanly mapped to URNs.
And don't bother with less.

Al