Subject: [alto] Progress on the unified properties draft and call for comments

From: Jensen Zhang <[email-masked]>
Date: Fri, 5 Jul 2019 18:02:37 -0400

Hi ALTOers,

After some internal discussions, we are happy to update to WG that we are
finalizing the unified properties draft. And below are some key design
points:

---

1. Consider UP (Unified Property Map) service as a unified ATLO information
resources query mechanism

ALTO defines different types of information resources, which have different
representation formats. But every information resource can map some kinds
of entities to some kinds of properties. e.g., a network map can map ipv4
to pid. UP provides a query mechanism to allow clients to get different
ALTO information resources in the unified representation format.

2. Each UP resource declares a set of (resource_i, DT) -> { (resource_ok,
Pk) } mappings

Here, resource_ok MUST be either resource_i or this (the current UP
resource itself).

- When resource_ok == resource_i, the mapping means the client can query
the property mapping DT -> Pk defined by resource_i. e.g., "ipv4" -> "pid"
defined by "networkmap-1".
- When resource_ok == this, the mapping means the client can query entities
in the entity domain resource_i.DT, and UP will return the property P
defined in its own backend database.

The semantics of entity domain resource_i.DT MUST be defined in the IANA
registry of resource type of resource_i
The semantics of mapping DT -> Pk MUST be defined in the IANA registry of
resource type of resource_ok.

2.1. Use DT -> { (resource_ok, Pk) } as a shortcut of the aggregation

A UP resource can declare "ipv4" -> { ("net1", "pid"), ("net2", "pid") }.
It is equivalent to the outer join of ("net1", "ipv4") -> ("net1", "pid")
and ("net2", "ipv4") -> ("net2", "pid"). In this UP, "ipv4" indicates the
union of entity domain "net1.ipv4" and "net2.ipv4".

3. The client sends the UP query based on the declaration

The client queries a list of entities in resource_i.DT or DT, and a subset
of properties { (resource_ok, Pk) }.

---

We will finish the document revision in the next two days. In the meantime,
your comments and feedback are highly welcomed.

Thanks,
Jensen

---

From: "Y. Richard Yang" <[email-masked]>
Date: Mon, 8 Jul 2019 12:10:12 -0400

Some quick additional comments. Please see inline.

On Fri, Jul 5, 2019 at 6:02 PM Jensen Zhang <[email-masked]>
wrote:

> 1. Consider UP (Unified Property Map) service as a unified ATLO
> information resources query mechanism
>
> ALTO defines different types of information resources, which have
> different representation formats. But every information resource can map
> some kinds of entities to some kinds of properties. e.g., a network map can
> map ipv4 to pid.
>

Slight clarification. So far it is not every type of information resource.
For example, cost may cannot yet, unless we introduce flow/connection, but
we may say some for now.

> UP provides a query mechanism to allow clients to get different ALTO
> information resources in the unified representation format.
>
>
We should clarify that UP provides 3 functions, as we did in the quad
chart: export, extend, and define. The preceding may give others an
impression that it limits us to only the first.

> 2. Each UP resource declares a set of (resource_i, DT) -> { (resource_ok,
Can we use r_i, d_i -> r_o, p_o?

> - When resource_ok == this, the mapping means the client can query
> entities in the entity domain resource_i.DT, and UP will return the
> property P defined in its own backend database.
>
I do not know what the outer join is. A simple rule is a kind of
*inheritance* rule:

d_i -> (ro1, po1), (ro2, po2), ...,

<=>

(ro1, d_i) -> (ro1, po1);
(ro2, d_i) -> (ro2, po2),
...

In words, the result is to use the output resource.

> 3. The client sends the UP query based on the declaration
It helps that we make clear the declare-use consistent design. Hence the
final format of capability may be:

// design 1
query-capability:         a list of mapping
mapping:                    domain -> properties

properties:                  a list of properties
property:                     resource-prop | this-prop
resource-prop:           r_o.p_o    // (r_o, p_o)
this-prop:                   .p_o         // (this, p_o)

domain:                     resource-domain | generic-domain
resource-domain:     r_i.d_i
generic-domain:       d_i

Semantics:
- resource-domain (r_i, d_i) -> properties
  is equivalent to (r_i, d_i) -> each property in properties

- generic-domain -> properties
  use the inheritance rule above

Consistency requirements:
Export consistency, which applies to
       an individual-mapping (r_i, d_i) -> (r_o, p_o), where r_i == r_o !=
this
     1.1 Capability announcement consistency:
            d_i -> p_o must be supported by resource r_i
     1.2. Content consistency
            (r_i, d_i) -> (r_o, p_o) lookup result is the same as one uses
r_i itself.
Extend consistency, which applies to
      an individual-mapping (r_i, d_i) -> (r_o, p_o), where r_o == this
   The domain (r_i, d_i) must be supported by r_i

Make sense?

Richard

> We will finish the document revision in the next two days. In the
> meantime, your comments and feedback are highly welcomed.
>
> Thanks,
> Jensen
>

-- 
-- 
 =====================================
| Y. Richard Yang <[email-masked]>   |
| Professor of Computer Science       |
| http://www.cs.yale.edu/~yry/        |
 =====================================

---

From: Jensen Zhang <[email-masked]>
Date: Mon, 8 Jul 2019 12:59:43 -0400

Hi Richard,

Thanks for your comments and some clarifications.

> For example, cost may cannot yet, unless we introduce flow/connection, but
Agree. We will clarify it is extensible. The future document can define new
mappings for existing ALTO information resources.

> impression that it limits us to only the first.
It will be clarified in the document.

> Thanks for your clarification. *inheritance* may be a better
clarification. the (ro1, po1) of d_i:e_i (an entity in d_i) inherits (ro1,
po1) of ro1.d_i:e_i (the entity in (ro1, d_i) with the same id).

> Thanks for your clarification again. I agree with the requirements above.
The document will include them.

Jensen

> Make sense?
>
> Richard
>
>
>> The client queries a list of entities in resource_i.DT or DT, and a
>> subset of properties { (resource_ok, Pk) }.
>>
>> ---
>>