Re: [xdi] Namespace delegation (was: Re: [xdi] Minutes: XDI TC Telecon Friday 2013-04-19)

[Drummond Reed <drummond.reed@xdi.org>]

On Mon, Apr 22, 2013 at 6:31 PM, Chasen, Les <les.chasen@neustar.biz> wrote:

I don't have strong enough feelings to debate but i feel that things that are likely to be more common are more complex, syntactically.  

Agreed.

 

It seems to me that having community namespaces will be common.  I don't think it will be common to classify those namespaces.

Under traditional non-semantic federated addressing, it's not even possible. Under semantic federated addressing, I believe it will be very common.

If les does exist under @neustar can he be referred to by both @neustar[+employee]*les and @neustar[*]*les.  I do have multiple classifications with Neustar.  

Yes. See below for more.

If a client knows les exists under @neustar but does not know the class how does he resolve les?

One of the other key considerations about namespace delegation that Markus and I discussed is how XDI addressing architecture significantly flattens out namespaces because it encourage everything to move up to the top level, i.e., have a globally unique ID that can be discovered in many XDI contexts. That's part of what shared semantics is all about.

So the easiest way to discover "Les" in the context of Neustar will be if the client knows the public personal cloud name or number for Les and then searches for it in the context of Neustar. So if your public personal cloud name was =les and public personal cloud number was [=]!:uuid:f81d4fae-7dec-11d0-a765-00a0c91e0001, the client could do discovery on either:

1. @neustar=les
2. @neustar[=]!:uuid:f81d4fae-7dec-11d0-a765-00a0c91e0001

From that subgraph the client should be able to find out all public roles Les plays at Neustar, e.g.:

• @neustar[=]!:uuid:f81d4fae-7dec-11d0-a765-00a0c91e0001/$is/@neustar[+employee]!12345
• @neustar[=]!:uuid:f81d4fae-7dec-11d0-a765-00a0c91e0001/$is/@neustar+engineering+director
• etc.

=Drummond 

 

From: Drummond Reed <drummond.reed@xdi.org>
Date: Monday, April 22, 2013 9:06 PM
To: Les Chasen <les.chasen@neustar.biz>
Cc: Markus Sabadello <markus.sabadello@xdi.org>, OASIS - XDI TC <xdi@lists.oasis-open.org>, Phil Windley <pjw@kynetx.com>
Subject: [xdi] Namespace delegation (was: Re: [xdi] Minutes: XDI TC Telecon Friday 2013-04-19)

[renaming thread to reflect the new topic]

Les, your point about "you can't have simple namespace delegation" anymore is the reason Markus and I spent an hour talking about it.

In DNS and other distributed naming services, that's just what you have: federated namespaces via delegation. And that's what we were initially trying to emulate with XRI architecture, just adding the semantics (and syntax) to distinguish between mutable (reassignable) and immutable (persistent) identifiers.

But what we found was that that wasn't enough benefit to justify the additional complexity.

With XDI addresses, we're moving to semantic addressing -- an address that communicates semantics about the resource you are addressing.

The thesis is that semantic addressing, paired with a semantic data interchange format and protocol will provide enough breakthrough benefits to drive adoption.

Semantic addressing still supports federated namespace delegation. But it means that an address is not just a string of delegated name. The names carry semantics. For example, in @neustar[+employee]*les, you know that @neustar is a globally unique singleton name for an instance of a group (in this case a company). You know that +employee is a class of resource available in the @neustar context. And you know that *les is the name of an instance of the employee class.

Markus and I explored whether we should introduce a new type of context symbol expressly for delegated naming, i.e., to emulate the way DNS and other federated haming systems work. Our conclusion was that this would:

1. Complicate the XDI model without significantly adding value.
2. Detract from the value of semantic addressing, because it would be intentionally stripping away the semantics.

So our conclusion was that XDI should stick to what it does best (and what to our knowledge it does uniquely), which is federated semantic naming. 

Thoughts?

=Drummond 

On Mon, Apr 22, 2013 at 4:07 PM, Chasen, Les <les.chasen@neustar.biz> wrote:

Wow … you can't have simple namespace delegation anymore?  

From: Drummond Reed <drummond.reed@xdi.org>
Date: Monday, April 22, 2013 5:32 PM
To: Markus Sabadello <markus.sabadello@xdi.org>
Cc: OASIS - XDI TC <xdi@lists.oasis-open.org>, Phil Windley <pjw@kynetx.com>
Subject: Re: [xdi] Minutes: XDI TC Telecon Friday 2013-04-19

- Community names such as =neustar*les don't work anymore, because the instance *les can't follow the singleton =neustar. Do you have any idea on how to solve this?

Markus and I talked about this for nearly an hour. The bottom line is that to be consistent with the full XDI graph model, *names and !numbers need to behave consistently as instances, which means they only follow a class (in square brackets). So it means that community names need to specify the class before the instance, e.g., =neustar[+employee]*les. Or they can use a cross-reference such as =neustar=(les). Or, for a pure name registry, it would be an instance of the mutable ID class, e.g., =neustar[*]*les. (Ugly but semantically consistent.)