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>
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
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:et... which ties the identifier to that specific instance of the topology service. 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