urn:ogf:network:domain=Internet2:node=packrat:port=eth0
Jeroen suggested:
The above examples both include *address* information in the *name*.
The URN syntax defines a relation between port and node (eth0 is in packrat), and between node and domain (packrat is in Internet2).
RDF defines a relation between name and lookup services (#packrat:eth0 can be looked up at http://www.internet2.org/i2.rdf).
We should be careful not to enforce users to include all kinds of relationships in a name. I would advocate a transport protocol (or database specification) that not only transmit (defines) names of objects, but also the explicit relations between different objects. I think I see the issue here. One of the goals of the URN schema was to not put the location of the element's definition into the identifier. The benefit of this is that it doesn't matter if the identifier's defiintion appears in an RDF file, on a topology service or wherever. It also doesn't matter if you move the location where the definitions occur. You could even switch between RDF and a topology service. NDL gets around this by mandating that everything be defined in RDF files and that the identifiers contain pointers to the RDF files where the definitions occur. We could do the same thing with a topology service URI: http://topology.internet2.edu:8080/perfSONAR_PS/services/topology#packrat:et.... If we did this, we'd be tying any external references (be they
Freek Dijkstra wrote: pathfinding, measurements, or whatever) to that specific instance of the definition. We'd not be able to move the topology service or split the data between multiple topology services or change the location of the RDF file without breaking external references. Currently, we can just email around if a change occurs, but if this does have widespread use, the email and update approach will quickly become unwieldy. To get around this, we would create a lookup service to convert an identifier into the location where its definition can be. If the identifiers are completely random, globally unique strings, all identifiers from all networks would need to be in the lookup service or they wouldn't be resolvable (and not just the external ones if clients want to lookup measurements for each element in the circuit that they've just allocated). To keep every lookup service from having to know every identifier, we have the domain portion of our ids. This allows the creation of an authoritative lookup service for the given domain (similar to DNS). The lookup services would then just have to know which lookup service is authoritative for each domain instead of knowing all the element identifiers in each domain. When clients wish to lookup the definition for a given id, they could consult their local lookup service who would redirect them to the authoritative lookup service for that domain. That is the only hierarchical mapping that would be required. Anything past that could be a uuid (i.e. domain identifier:uuid). Our URN structure does define a hierarchy below the domain that people can use so that identifier could make sense to outside parties, but doing so is not mandated at all. 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, we'll need to somehow encode this difference in the identifier scheme. Even in the case where we include the location directly, we'll need to differentiate between the various identifiers we might have (e.g. RDF identifier, Topology Service identifier, etc). Also, if we use the logical concept method, what approach should be used? domain? something else? Cheers, Aaron