[Nml-wg] Naming
Aaron Brown
aaron at internet2.edu
Fri Mar 28 07:40:01 CDT 2008
Freek Dijkstra wrote:
>> urn:ogf:network:domain=Internet2:node=packrat:port=eth0
>
> Jeroen suggested:
>
>> http://www.internet2.org/i2.rdf#packrat:eth0
>
> 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:eth0.
If we did this, we'd be tying any external references (be they
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
More information about the nml-wg
mailing list