W3C home > Mailing lists > Public > www-rdf-dspace@w3.org > June 2003

Re: SIMILE PI Call, 27-July-2003, 1200 EST / 1700 BST

From: Kevin Smathers <kevin.smathers@hp.com>
Date: Mon, 30 Jun 2003 11:14:35 -0700
Message-ID: <3F007E0B.3090603@hp.com>
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 EDT

This archive was generated by hypermail pre-2.1.9 : Wednesday, 24 September 2003 13:35:25 EDT