RE: Proposal: new top level domain '.urn' alleviates all need for urn: URIs

> -----Original Message-----
> From: ext Leo Sauermann [mailto:leo@gnowsis.com]
> Sent: 09 July, 2003 19:51
> To: Stickler Patrick (NMP/Tampere); Rdf-Interest
> Subject: RE: Proposal: new top level domain '.urn' alleviates all need
> for urn: URIs 
> 
> 
> Sorry that I didn't explain the ideas. Bad practice. I am 
> deep in philosophy right now, and a little off the subject, 
> you are right. I will explain the ideas more practical. I 
> think the problem in our communication was that you know much 
> about URNs and I just have to catch up on that, I did that now.
> 
> I will write my own solution at the end of the mail and do a 
> short comment on each discussion point:
> 
> > -----Original Message-----
> > From: Patrick.Stickler@nokia.com 
> [mailto:Patrick.Stickler@nokia.com] 
> > Sent: Wednesday, July 09, 2003 10:32 AM
> > To: leo@gnowsis.com; www-rdf-interest@w3.org
> > Subject: RE: Proposal: new top level domain '.urn' alleviates 
> > all need for urn: URIs 
> > 
> > How is
> >    urn:issn:1560-1560
> > superior in any way as a name to
> >    http://issn.urn/1560-1560
> > 
> > ???
> > 
> > I can argue that the latter is superior to the first
> > because it is meaningful to the HTTP protocol, providing
> > a proven and globally deployed means of obtaining 
> > representations, and with URIQA a future globally
> > deployed means of obtaining descriptions.
> 
> that is what I have in mind, using the http:// scheme 
> primarily to create URIs, so we have a fallback procedure: a 
> user can point his browser there and see <something>.
> 
> <something> would ideally be a HTML representation of the RDF 
> boundary description uriqa describes. This is right, or ?

Well, it would be a representation of the resource denoted
by the URI.

The key motivation for urn: URIs was that folks wanted identifiers
that were not mnemonically or organizationally tied to a particular
legal entity and would be persistent irrespective of changes
in organization and ownership.

So if company X owned a book, they could assign it a non-mnemmonic
urn: URI and if they later sold that book to company Y, there
wouldn't be any difficult trademark issues and the like. Or if
there were dozens of points of access to the resource, per
load balancing or global distribution needs, one could inquire
(somehow) about the best "location" and access the resource
accordingly.

http: URIs were rejected because they were tied to domain names
which either (a) had mnemmonic and/or trademarked characteristics
and (b) were not guarunteed persistent because domains (typically)
can transfer to new owners or become defunct.

But, having a top level domain for URNs which is owned and
managed by the same organization now managing registration
of urn: subschemes and which, by agreement by the powers that
be that such a top level domain would never be reused even
if the managing organization became inoperable or ceased to
exist, would remove those criticisms against http: URIs.

An HTTP URN http://X.urn/Y would be no more mnemmonic than
urn:X:Y and (given the expected special case of the root
domain) would be just as persistent.
 
> > > having two different things kills the human readable 
> > factor. and it is
> > > no good design, programmers SENSE tells you to avoid redundancy.
> > > 
> > > USE OWL !!!
> > > http://www.w3.org/TR/2003/WD-owl-guide-20030331/#sameIndividualAs
> > > and you are done with changes.
> > 
> > Err.... I think you are arguing against a misunderstanding
> > of something I didn't say (and I'm not even sure what it is
> > you think I've said...)
> 
> I meant what you answered with the good "this information has 
> moved" example :
> 
> > GET http://issn.urn/1560-1560 HTTP/1.1
> > URI-Resolution-Mode: Description
> > statements such as
> >   <http://issn.urn/1560-1560> owl:sameAs <...> .
> 
>  
> > What two different things are you talking about?!
> 
> I missunderstood you, I thought you wanted to have one NAME 
> for a resource that is a URN and one locator to a resource 
> that is a URL, I didn't know that URNs include a resolving 
> algorithm. But an urn includes information where to find the 
> data so that is fine.

A urn: URI would rely on a global mapping solution such as
DDDS which would provide another URI, typically an http: URI
via which representations of the resource could be obtained.

An HTTP-URN, as I propose, would be similar in that there would
typically be a redirection (mapping) to another URI where
representations of the resource are managed.

The difference is that DDDS is yet another piece of 
architecture, and one that is not, and won't for some
time, be globally deployed (if ever); yet redirection,
as employed for HTTP-URNs is everyday-business on the
web.

> > The motivations for creating the special URI scheme urn: as
> > a separate solution from http: URIs simply lose all weight
> > in light of what I am proposing and what has been proposed
> > previously in the work done on PURLs.
> 
> we will probably end up with the urn: scheme, or even 
> something like rdfp: for a rdf protocol. 
> In my own work I use 
> rdfp: sometimes as a "dirty hack workaround"...

I expect that solutions such as HTTP-URNs (a'la PURLs)
and URIQA will lead to the obsolescence of such methods.

And that will be augmented by further work and deployment
of a more general, standardized RDF Query API.

But, as we all know, the future can often turn out
different from what we expect ;-)

> > Argh! This is precisely one of the key motivations for the
> > proposal in question! To meet all of the needs of those who
> > want urn: URIs but with the existing HTTP machinery!
> > 
> > Have you even read my original post, or are you just misinterpreting
> > random comments far along the thread of discussion?
> 
> misinterpreting random comments together with chronic 
> ignorance, sorry for that.
> 
> 
> 
> Now to something worth of interest for you all (I hope)
> 
> 
> 1. Scalability
> 
> We are not talking here of the payload a DNS systems has or 
> any similar system has, we will have a payload that may 
> include all database systems on the world and all webservers 
> of the world with every request.
> Because when a client wants to know something about 
> "http://iss.urn/1560-1560" he has to do a URN resolution. 
> Example: Client Leo surfs to Nokia and looks at a product 
> list with 1000 entries. For each product, the server will do 
> a URN resolution to find the right webserver in the nokia 
> company that has the information. Assume that the product 
> list is distributed on different parts of Nokia: In the list 
> are Telephones which are handled by server X, others are GSM 
> antennas for companies which are on server Y (different 
> Organizational Unit), etc. 
> When I browse through my local addresslist in Netscape, the 
> contact identifiers may be based on urn and all point to my 
> localhost, but still need some kind of address resolution.
> 
> I think that in the future every access to any information 
> anywhere will include a resulution of a URI or URN. 
> 
> I hereby make the prophecy: database ID's will die out. 
> 
> So I don't think that any dynamic "search for the server with 
> more than plain DNS" structure will handle this payload. 
> Everybody can argue here with ddns or urn: but these 
> technologies have not been proven in this payload. 
> 
> ! Surely, you will gain much in local buffering of URN's, 
> that may prove to solve the problem !
> 
> Also, Patrick Stickler mentioned in [1] that the resolution 
> of HTTP URNS becomes a business/social issue.
> -> well, it becomes an issue that could be avoided perhaps.
> 
> With DNS, its easier because i don't have to resolve the 
> whole URI but only the servername, which can be buffered by 
> the OS or nslookup. And is buffered by my local DNS servers of my ISP.
> 
> Therefore I suggest sticking to the existing http: URLs that 
> have some advantages:
> HTTP URLS
> - domain names are already bought by people and can be used
> - most companies have intranets and websites
> - resolution is only once for a server
> - there are organizational structures that control who when 
> how creates webspace und domains in companies.

I don't expect that every URI will be a URN requiring
the indirection inherent in either DDDS or my HTTP-URN
proposal. URNs are a very specialized kind of name, 
motivated by very particular needs. The lion's share of
all URIs will not require either the mnemonic/legal opacity
or the guarunteed persistance that are the defining
requirements for URNs.

So in general, I agree with your overall sentiments as
expressed above, but point out that a DNS only approach
will fail to meet those key requirements of URNs. 

> (how fine this 
> works: example by Graham Klyne see [3])
> 
> My Resolution Solution 
> ======================
> (i call it gnowsis, but perhaps its too obvious to be an 
> autonomous idea :-)
> that already runs in small scale (simple but works):
> 
> I myself build a server (gnowsis server) right now that 
> functions more in a Apache-Module way:
> Each organizational unit gets or already has a host with 
> domain name (f.e. crm.ibm.com)
> this unit holds all information that it is responsible for on 
> this server, with write access only for members of the Unit 
> (f.e. crm.ibm.com/customers/112321312 points to a customer)
> the webserver has modules that are trained to retrieve the 
> different data out of different data sources, f.e. retrieving 
> the telephone number of the customer out of SAP.
> 
> The existing webserver is upgraded with a Gnowsis-Module that 
> does the new protocol and filters out RDF requests.
> The gnowsis module returns RDF data, it may work using the 
> URIQA protocol together with Joseki and Sesame protocol.
> 
> A security system restricts access.
> Projects, products or other resources are identified by their 
> most publicly known uri, example:
> http://www.nokia.com/nokia/0,,4486,00.html
> this is a Nokia 6800 mobile phone for a customer, as given by 
> the Nokia Marketing people.
> 
> If the r&d branch of nokia thinks that they need something 
> else, fine, they have their own server:
> http://rd.nokia.com/research/products/6800abcxyz
> 
> and then you have some nokia dedicated index server that does 
> nothing but store connections like that:
> http://rd.nokia.com/research/products/6800abcxyz 
> owl:sameIndividualAs http://www.nokia.com/nokia/0,,4486,00.html
> 
> This "distributed knowledge" approach has been proven in 
> running projects on one of the biggest Construction companies 
> of Italy by Matteo Bonifacio of the University of Trento, 
> read their interesting paper at [4] and also other Bonifacio 
> papers are interesting [5], for example [6]

And, err, by Nokia too ;-)

Again, all well in good for employing redirection simply
for organizational benefit. But it still fails to provide
for the needs of URN lexical opacity.

For URNs, redirection of some kind is manditory, not
just optional.

> My Idea has been evolved independently and is more RDF 
> oriented but the paper at [4] relieved me by providing some 
> scientific and practical proof.
> 
> Matteo's approach is to let people use their own databases 
> and ontologies and then build automatic tools that match the 
> ontologies (automatic creation of some "sameAs" entry). I 
> don't agree with everything in that theory but it worked 
> perfectly in projects they did.
> 
> This idea has one flaw: It is not global. It is company focused.
> you cannot get "what are the owl:sameIndividualAs of this uri X"
> but you can resolve X and ask the server that hosts X for 
> owl:sameIndividualAs
> and if that is not enough, you may google (google will be the 
> first company to do a semantic web search engine I think...)

But only if they wake up and realize the opportunity.

I keep waiting to see something akin to http://sw.google.com/URIQA?...  

;-)

> the second thought "Identity and Human Factor" I will publish 
> in a new thread, it is a new (more basic research) idea that 
> can be perhaps included in the thinking of URIQA.

I look forward to reading it.

Regards,

Patrick



> 
> alas, this is long
> Leo Sauermann
> www.gnowsis.com
> 
> 
> 
> [1] 
http://lists.w3.org/Archives/Public/www-rdf-interest/2003Jul/0048.html

> However, in the best case scenario, and one which I expect will
> be the norm, the managing organization will provide an effective
> PURL or PURL like service for their customers.
Being the entire web.  PURL like services are effective in inverse 
proportion to the number of people or machines that use them.
[2]http://lists.w3.org/Archives/Public/www-rdf-interest/2003Jul/0055.htm
l

[3]
http://lists.w3.org/Archives/Public/www-rdf-interest/2003Jul/0062.html

[4] Knowledge Nodes: the Reification of Organizational Communities. A
Case Study, R.Cuel, M. Bonifacio, M. Grosselle, in Proceedings of
IKnow'03 p40.

[5] http://edamok.itc.it/dissemination/pep.htm
[6] http://edamok.itc.it/documents/papers/informatik.pdf

Received on Thursday, 10 July 2003 08:38:58 UTC