[Nml-wg] Naming

[Aaron Brown]

Freek Dijkstra wrote:
>> NDL [mandates] that everything be defined in RDF files and that the 
>> identifiers contain pointers to the RDF files where the definitions 
>> occur.
>
> First of all, NDL does not mandate that. Nowadays, some RDF gurus say 
> that RDF does, but that is not in the original design. I could just as 
> easily write in RDF:
>
> <Port id="urn:ogf:network:domain=Internet2:node=packrat:port=eth0">
> <lookup-service>http://topology.internet2.edu:8080/perfSONAR_PS/services/topology</lookup-service> 
>
> </Port>

Fair enough, but that ends up recreating the topology identifier i 
talked about in the email: 
http://topology.internet2.edu:8080/perfSONAR_PS/services/topology#packrat:eth0 
which ties the identifier to that specific instance of the topology service.

>> Basically, this all comes down to (assuming I have this right), do we 
>> tie the identifiers to the location of the element's definition or do 
>> we tie the identifiers to a logical concept so that the identifiers 
>> are independent of the definition's location? And if the answer is both, 
>
> My preferred answer is none (don't tie identifier with anything) -- 
> make it all explicit.
>
> For example, to make everything really explicit, you'll get:
>
> <Port identifier="urn:internet2.edu:UkRGIHN0aWxsIHJ1bGVzIQo">
>    <name>eth0</name>
>
> <lookup-service>http://topology.internet2.edu:8080/perfSONAR_PS/services/topology</lookup-service> 
>
>    <inDevice><ref 
> identifier="urn:internet2.edu:UmVhbGx5IHNvCg"/></inDevice>
>     <inDomain><ref 
> identifier="urn:internet2.edu:a2lkZGluZy4uLgo"/></inDomain>
> </Port>
> <Node identifier="urn:internet2.edu:UmVhbGx5IHNvCg">
>     <name>packrat</name>
> </Node>
> <Domain identifier="urn:internet2.edu:a2lkZGluZy4uLgo">
>     <name>Internet2.edu</name>
> </Domain>
I'm fine with being explicit about which device and domain an element is 
in. In fact, that relation is captured directly in our schema (not just 
with the URNs).
> Indeed, this is verbose. But you don't have to give out all 
> information every time. Typically, a protocol should send the lookup 
> service or domain information to a neighbour when it first mentions a 
> port. With that, the neigbour can create its own local lookup table. 
> So it's distributed and flexible.
I'm thinking beyond simply path finding. What do we do when a user wants 
to get the status of all links along the circuit and check what's going 
on with the routers connecting those links? He's given back a list of 
identifiers for each link in the path of the form URN 
"urn:internet2.edu:UkRGIHN0aWxsIHJ1bGVzIQo". Who does he contact to find 
out where he can get monitoring information about that link let alone 
the routers? If the link happens to be a neighbor, he can consult the 
local lookup table. What if it's not? Do we return the lookup service 
for each element every time?

This whole thing seems to boil down to there being the two pieces of the 
identifiers "namespace" and "identifier-in-namespace". The namespace is 
used to tell a client what to look up to find the location of the 
element definition and the identifier-in-namespace tells the client 
which element specifically to ask for at that location. NDL (or just the 
files I've seen) use the RDF URL as the namespace and the identifier in 
the namespace is the anchor in the RDF file. Our scheme uses the domain 
field of the URN to define the namespace. The rest of the URN defines 
the 'identifier-in-namespace' and can be nearly identical to what you've 
proposed or hierarchical depending on the desires of whoever is 
labelling these elements.

I'm not sure either is specifically better than the other, but we should 
define how these namespaces are created and how they should retain 
global uniqueness, and how to differentiate the namespace from the 
identifier in the namespace. I like the use of domain names since people 
already understand and recognize them. They also recognize URLs, but if 
URLs(either of the webservice or RDF variety) are used, it either does 
tie or implies a tie between the identifier and a specific service 
instance or file.

Cheers,
Aaron