Subject: Re: Handling closed sets of feature values

From: Graham Klyne <[email-masked]>
Date: Thu, 10 Sep 1998 21:57:29 +0100

At 14:41 09/09/98 -0700, Ted Hardie wrote:
[...]
>On Sep 9,  6:47pm, Graham Klyne wrote:
>> Subject: Handling closed sets of feature values
[...]
>> (a) Do nothing.  It may be that the problems are not serious in practice.
>
>Your font examples are quite enough to demonstrate to me that we
>cannot do nothing.  If we do we will either end up with a ridiculously
>large set of feature tags or a system which flat does not work.

No argument from me.  But I thought the possibility should be considered.

>> (b) Introduce set-valued features.  Comparison would be based on set
>> equality and inclusion.  This introduces a possible complication that the
>> resulting set is partially ordered -- I'm not fully sure of the
>> implications of that fact.
>>
>> This would lead to a recipient predicate like this:
>>     (Font<={"Times","Swiss"})
>> which would match this document predicate:
>>     (Font={"Times","Swiss"})
>> but not this:
>>     (Font={"Times","Rarity"})
>> (where '<=' operates as a subset comparison)
>>
>
>Just to make sure that the use of these symbols in this context does
>not confuse, let me translate this into English as:
>
>Recipient capabilities
>(Fonts available are {"Times", "Swiss"})
>
>Matching document predicate
>(Fonts required are {"Times", "Swiss"})
>
>Non-matching document predicate
>(Fonts required are{"Times", "Rarity"})

I agree with the above (in this context).  That is '<=' implies available,
even though they may not be used.  '=' implies used, hence must be available.

>I am afraid I don't quite understand above when you say that
>the resulting set will be partially ordered.  Can you clarify
>that?

The data type of the feature tag would be the powerset of individual
values.  That is the set containing all possible sets of values.  The
ordering relationships '<=' and '>=' would be based on sen inclusion.  But
if one has two sets where neither is a subset of the other, there is no
ordering relationship between them.

Contrast this with a fully ordered type like numbers:  given any pair of
numbers then exactly one of the relations '<', '=', '>' is applicable.
This is not so with a partially ordered set.

This is a very theoretical consideration:  it may not matter.  Thus far, I
have not had time to think about this an form an opinion.  I hope it does
not matter, but ...

>> (c) Introduce a way of tagging "required" features.  If one party indicates
>> that some feature must be present for feature set matching to proceed, then
>> the feature set matching process could be modified to ensure that the
>> feature exists with a default value in each feature set that is being
>> matched.  I think this would tend to confuse the feature set matching
>> prodcess by changing it away from being a simple process of pure logical
>> manipulation.
>
>I think we are going to have enough problems with preference indicators
>that using a required tag to indicate set values is a bad idea.

Not being able to formulate "required" values in a purely logical
expression, I tend to agree.

>> (d) Feature tag schemata:  for example, defining a feature tag of the form
>> "Font-*" so that any Font-xxx value can be matched.
>>
>> Thus, to describe the font capabilities of a recipient, one might use:
>>     (& (Font-Times=TRUE) (Font-Swiss=TRUE) (Font-*=FALSE) )
>> which would match a document described as:
>>     (& (Font-Times=TRUE) (Font-Swiss=TRUE) )
>> but which would not match a document described as:
>>     (& (Font-Times=TRUE) (Font-Rarity=TRUE) )
>>
>> Defining exact rules to make this work could be a challenge.
>
>I can't see how it would work at all for tags in the faceted group.  How
>will someone using a u. feature tag create or indicate that a tag was
>part of one of these schemes?

Good point.  I hadn't thought of that.  But in any case, I think (e) below
formalizes the approach more cleanly.

>>
>> (e) Use auxiliary predicate as a feature tag.
>>
>> A recipient might define:
>>     (Font X) :-
>>       (| (X="Times") (X="Swiss") )
>> Then a document might assert:
>>     (& (Font "Times") (Font "Swiss") )
>> which would match, or
>>     (& (Font "Times") (Font "Rarity") )
>> which would not match.
>>
>> I see the challenge in this case is to define clear scoping rules for
>> locating the auxiliary predicate.  I view this as a 'cleaner' version of
>> solution (d) above.
>
>This clearly would work better for the faceted groups, because the
>definition would take place prior to the use of the auxilary predicate,
>but within the same exchange.
>
>
>My first take is that (b) and (e) are the most promising candidates,
>and that (b) looks simpler than (e).  Which would you see as easier
>to fit into the larger construct?

I tend to agree.  (b) may be simpler *if* the partial ordering issue
doesn't bite, though it would require some additional syntax (and an
extension to the data types section of the registration document).  (e) has
the advantage that the underlying mechanism ('auxiliary predicate') might
be useful in other ways.  The fact that (b) seems more intuitive is a big
argument in its favour.

Are there any other ways to skin this particular cat?

#g

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

---

From: Graham Klyne <[email-masked]>
Date: Wed, 23 Sep 1998 20:01:18 +0100

At 19:25 15/09/98 +0200, Koen Holtman wrote:

[...]
>>The example cited was how a receiver can indicate that they have some given
>>set of fonts, *and no others*.

[...]
>Speaking from my background in symbolic logic, it is advisable to have
>an algebra in which it is possible to say things like "all these
>atomic predicates are true and no others are true", and to build your
>semantics on top of such statements.  If you try to go for a system
>which has no concept of "these are true and all the others are false",
>not even on a meta level, you end up with something that may work for
>negotiation, but will be too difficult for the average user to
>understand and for the average program to bother implementing.

I agree with you... to a point.  My disagreement is that to say "X is true
and all other statements are false" implies that one can have total
knowledge about what you are describing.  While you might have total
knowledge about some aspects of a receiver (e.g. the total set of fonts it
can support) there may be other aspects about which one does not have
knowledge (e.g. what media type is in the paper tray).

Therefore, to pursue your way of presenting the issue, there needs to be a
way of scoping the predicates in some way so that within some defined scope
one can say "all these are true and all other statements are false".

This gives me a different way of looking at the problem ... I shall go away
and see if I can think of any other possible solutions.

#g

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