Troublesome Questions about TIE Naming

Troublesome Questions about TIE Naming

1. Goals

1. Determine how Frame Names, KR Names, and KB Names look and function.
2. Address issues concerning KBs, frames and KRs.

2. Assumptions

2.1 Let us assume these BNFs

<frame label> ::= <let-num> [ 1,31<let-num-hyp>]

eg Fred-W-Smith
<frame label> is a string which is guaranteed to be unique within the KR in which it was created.

<kr-name-chars> ::= <let-num-hyp> | "."

<kr-name-chars> is a set of character including all letters and digits as well as the hyphen and the period. These are the only characters (check on the _ underline) which appear in host and domain names and are therefore suitable for composing kr names.

<kr name> ::= <let-num> [ 1,31<let-num-hyp>]

eg COM.EMERGENCE.PRIVATE
<kr name> is a string which is guaranteed to be unique to a particular KR if the administrators of the EMERGENCE.COM domain see to it that that is the case.

3. Possible BNFs for <frame name>

3.1 frames without context -- a silly proposal

<frame name> ::= <frame label>

example

Fred

discussion

This is clearly unacceptable.because frame labels are only guaranteed to be unique within the KR of their origination. This means that there is no guarantee that they will be unique between KRs and consequently they are not suitably unique identifiers for universal application. In particular, KR₁ would not be able to distinguish a frame called Fred that it had created from a frame called Fred that KR₂ had created.

pros

1. Gosh, it is simple! Hmm, perhaps too simple...

cons

1. KRs have no way to determine when a frame name indicates that the frame is available from some other KR
2. KRs have no way to guarantee the creation of frame names that are globally unique without recourse to checking each new name with all other KRs at the time of creation.

3.2 frames in the context of KRs

<frame name>   ::= <frame label> + "@" + <kr name>

example

Fred@COM.EMERGENCE.PRIVATE

discussion

By mixing the <kr name> into the <frame name> we obtain uniqueness for frames across all KRs. Knowing a frame name of this sort means that (through the use of the DNS-like architecture described above 2.2) it is possible to locate the frame referenced.

pros

1. frames have an existence outside of KBs, that is: each frame could exist in more than one KB (is this a pro?)
2. a frame could exist without being in any KB.

cons

1. with this scheme it seems as if the two styles of mirroring which would make sense would be either individual frames or whole KRs.
2. another way of saying this is that it is less clear how the mirroring of whole KBs is likely to occur

3.3 frames in the context of KBs and KRs

<kb name>      ::= <frame label> + "@" + <kr name>
<frame name>   ::= <frame label> + "!" + <kb name>

examples

PeopleWithoutLastNames@COM.EMERGENCE.PRIVATE
Fred!PeopleWithoutLastNames@COM.EMERGENCE.PRIVATE

discussion

Note that each KB has a special frame associated with it that tells us about the KB -- PeopleWithoutLastNames@COM.EMERGENCE.PRIVATE -- in this case.

pros

1. when obtaining an access method suitable for the frame this approach also means that an access method suitable for the entire KB in question will be returned.
2. the frame is returned in the context of a kb. This is good when we wonder about how suitable it is to have a frame which might (if available in the context of more than one kb) gradually acquire evaluations, annotations and so on which are particular to the kb context in which it appears.

cons

1. the independence of frames from kb is called into question (is this a con?)

3.4 frames in the context of KBs

<kb name>      ::= <REVERSED DOMAIN NAME> + "." + <frame label>
<frame name>   ::= <frame label> + "!" + <kb name>

example

COM.EMERGENCE.PeopleWithoutLastNames
Fred!COM.EMERGENCE.PeopleWithoutLastNames

discussion

This approach identifies frames as having significance within the context of KBs. It does not neccessarily mean that a frame belongs to one and only one KB (though it would probably be easier if it did.) The inclusion of the <reversed domain name> in the <kb name> is very interesting because it tells us how to learn the access methods for a KB: just ask the domain's KNS server (in this case: COM.EMERGENCE.KNS see 2.2).

pros

1. Having frames defined (or at least accessed) within the context of a KB enables things like annotations and evaluations to be accessed within the context of the appropriate KB
2. Associating frames with KBs (rather than with KRs) makes it easy to see how to distribute access to the frame -- just have the KNS negotiate with the supplicants about whether they should talk to a mirror KR or the authoritative KR to obtain access to the KB in question.
3. Having the reversed domain name in the KB name provides confidence about the uniqueness of the KB name

cons

questions

• Are evaluations and annotations performed in the context of a kb?
• Are they always?
• Can we identify the exceptions? (unlikely)
• Would it be better to permit annotations (at least) and evaluations (possibly) to occur by default within the context of a kb but optionally outside of the context of any particular kb, that is to say: on the frame itself?