Some quick additional comments. Please see inline.
On Fri, Jul 5, 2019 at 6:02 PM Jensen Zhang <[email protected]>
wrote:
> 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.
>
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,
> Pk) } mappings
>
>
Can we use r_i, d_i -> r_o, p_o?
> 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".
>
>
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
> 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
>
--
--
=====================================
| Y. Richard Yang <[email protected]> |
| Professor of Computer Science |
| http://www.cs.yale.edu/~yry/ |
=====================================
_______________________________________________
alto mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/alto
