- 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