- From: Kevin Smathers <kevin.smathers@hp.com>
- Date: Mon, 30 Jun 2003 11:14:35 -0700
- To: "John S. Erickson" <john.erickson@hp.com>
- Cc: simile-w <www-rdf-dspace@w3.org>
John S. Erickson wrote:
>Rob said:
>
>
>>Rob to give access to SIMILE IPSSources area to Jason
>> and PIs
>>John to summarise Handle/DOI/DNS issues raised in call
>> and mail www-rdf-dspace
>>PIs to read section 4.2.1 in relevant tech doc (Security
>> and Policy) and give feedback to Kevin
>>
>>
>
>JSE: Regarding Handle System vs. DOI vs. DNS, the issues invariably condense
>down to a need to differentiate between the capabilities of these regimes and
>map those onto the requirements of SIMILE, moving foward.
>
>1. A core argument of the Handle System is scalability and extensiblity beyond
>DNS. One way to interpret this is, whereas the top-level domain of DNS is
>artificially constrained (this is the ".com," ".edu," etc. level), the Handle
>System provides unlimited, self-administering "top-level domain" equivalents,
>known as HS "Naming Authorities."
>
>
I don't buy this argument. The top level DNS domains are essentially
categories, they are analogous to HS preallocating block number ranges
for certain classes of naming authorities (e.g. Simile). That DNS
defines certain well known categories, while HS does not only leads to a
minor feature distinction; it doesn't fundamenally alter the scalability
of either system. Properly characterized, the HS self administered
naming layer should be mapped to the DNS self administered naming layer.
>2. NA-level self-administration has implications like, the remainder of the
>DNS formalisms (second-level domain, sub-domain, etc) are unnecessary --- or,
>more precisely, these formalisms are defined by the governance of the
>particular NA and are not dictated by HS itself. The equivalent of this in DNS
>would be if .edu, .com, .mil, etc. could set their own rules for entitlement.
>
>
No, it is as if in DNS the second level domains e.g hp.com, yahoo.com,
etc., could set their own rules for entitlement. As indeed they can, as
can any subdomain that they further delegate control to.
>3. The HS is built differently; in particular, it has built-in distributed
>access control for adminsitration.
>
>
DNS by contrast has non-built-in distributed access control for
administration. Indeed it has many different distributed administration
interfaces, from web UIs, to programmatic dynamic update libraries, to
'ssh into the DNS server and use vi to update the name tables'. I would
expect the HS approach to be more useful for certain applications, and
wildly inadequate for others. DNS is flexible enough to support exactly
the same applications as HS, but not consistent enough to support them
throughout the entire name space.
The other main feature the Larry brought up was that the numeric
identifiers of HS are less likely to be confused with trademarks and
other company identifying information so they will be more portable
across corporate boundaries than DNS. However, I don't believe there is
anything that prevents companies from requesting
meaningless DNS domain names; it just hasn't been very attractive.
>The distinction between HS and DOI is multi-faceted:
>
>1. DOI operates as an Naming Authority (NA) within the Handle System, and all
>that this implies. By definition, it defines the rules of entitlement to names
>within the hdl:/10.* namespace
>
>2. Leveraging (1), it is the intention of the DOI to be a "digital identifier
>of objects," both "real" and abstract. This means DOIs can be created that
>discribe e.g. an abstract "work" as well as manifestations of those works and
>copies of those manifestations. Proscribed and consistent models for metadata
>registration (so-called "kernel" metadata and domain-specific metadata
>following registered "application profiles") enable these sorts of
>applications. These standard models are implemented by defining how metadata
>is registered within the HS
>
>3. Leveraging (2), standard data structures and mechanisms can be defined
>within the NA-administered name space to define a consistent basis for
>interaction. DOI does this with (2) plus the DOI-API, which allows DOI-based
>applications to "play" consistently at a higher level of abstraction than the
>Handle System.
>
>
>
Since DOI depends on HS, if we need to incorporate DOI then we should
probably incorporate HS as well. In the absence of DOI, I don't think
that HS adds anything of technological significance to the system that
can't be done equally well with DNS. Technological issues aside, HS may
change thought patterns somewhat, or it may represent a newer and
therefor cleaner namespace.
There is nothing that I can find in HS that is incompatible with
Genesis, but I also don't think that it adds anything new.
Cheers,
-kls
--
========================================================
Kevin Smathers kevin.smathers@hp.com
Hewlett-Packard kevin@ank.com
Palo Alto Research Lab
1501 Page Mill Rd. 650-857-4477 work
M/S 1135 650-852-8186 fax
Palo Alto, CA 94304 510-247-1031 home
========================================================
use "Standard::Disclaimer";
carp("This message was printed on 100% recycled bits.");
Received on Monday, 30 June 2003 14:15:57 UTC