W3C home > Mailing lists > Public > uri@w3.org > December 2007

RE: URIs & Namespaces

From: Mike Schinkel <mikeschinkel@gmail.com>
Date: Sat, 8 Dec 2007 23:36:53 -0500
To: "'Erik Wilde'" <dret@berkeley.edu>, <uri@w3.org>
Message-ID: <097401c83a1d$2067df40$0702a8c0@Guides.local>

Eric:

For what it is worth, I completely agree with your thoughts regarding the
use of URLs to identify place names and have similar interests. As a matter
of fact, I've been wanting to develop a process to cultivate and maintain a
global list of URLs for placenames has been a goal of mine for several years
now.  I'd love to discuss your needs and use cases and tell you about my
ideas perchance we may be able to collaborate on a mutually beneficial
solution.

-- 
-Mike Schinkel
http://www.mikeschinkel.com/blog/
http://www.welldesignedurls.org
http://atlanta-web.org 

P.S. I'm also saddened by the many who take the position Mr. Gilman takes
that nothing short of the "100% perfection" of RDF is acceptable. If that
attitude were taken regarding the still less-than perfect HTML, we'd never
been able to benefit from the explosion that has been the web.

 

> -----Original Message-----
> From: uri-request@w3.org [mailto:uri-request@w3.org] On 
> Behalf Of Erik Wilde
> Sent: Saturday, December 08, 2007 3:13 PM
> To: uri@w3.org
> Cc: Al Gilman
> Subject: Re: URIs & Namespaces
> 
> 
> hello al.
> 
> thanks for your reply. i am not sure i completely understand 
> what you are saying, but i do understand that you think that 
> the whole idea of placename uris is not a good one.
> 
> > For placenames, a URI namespace is a bad idea.
> > This is because a namespace among URIs presumes a partition in the 
> > semantic domains.
> 
> yes, and this is what i want. i think that place names are a 
> very common concept, but they are also often used in highly 
> contextualized ways, so that they only make sense to specific 
> user groups. and that's fine, i just want to have a universal 
> way how this can be expressed.
> 
> > This is what is right about RDF: it takes a graph.
> 
> this debate in the place name application area could probably 
> completely mirror the debate in the microformats vs. rdf 
> field. by which i mean: do you favor an approach with 
> disconnected islands of semantics, or do you envision a 
> complete description framework in which everything can be 
> connected and maybe will be connected, at least ideally.
> 
> i don't want to get into that debate here, but i am 
> definitely more on the microformat side, for technical and 
> for philosophical reasons, so i have no problem if 
> descriptions cannot be fully connected.
> 
> > The schema of schemas is a graph, and so it takes a graph-mungeing 
> > calculus to manage metadata.
> 
> yes. iff you choose to favor the rdf world-view.
> 
> > Then use the concept variously termed
> > - localized name -- in desktop APIs
> > - label - in SKOS and ISO/IEC 24752-5
> > to link these interoperable data with the colloquial placenames.
> 
> we are actually working on this. we have a description 
> language for place name vocabularies, which describes how 
> place names map to wgs84-based geographic descriptions. but 
> this (a) can be replaced by something else if people want to 
> describe their place names in a different way, or it (b) can 
> be ignored if people don't want to describe the place names 
> beyond assigning names to places that are meaningful to them. 
> so my goal is to be able to name and identify a place that is 
> meaningful to a group of users and/or applications. whether 
> my specific approach of supporting namespaces is a good one, 
> is something i am not really sure about, but apart from that 
> question, i am still wondering whether there is some general 
> rule of how the namespace question should be handled in a uri scheme.
> 
> thanks and kind regards,
> 
> erik wilde   tel:+1-510-6432253 - fax:+1-510-6425814
>         dret@berkeley.edu  -  http://dret.net/netdret
>         UC Berkeley - School of Information (ISchool)
> 
Received on Sunday, 9 December 2007 04:37:07 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:25:11 UTC