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 ?




> > 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.


> 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"...


> 
> 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. (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]

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...)


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.


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