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

Re: URIs & Namespaces

From: Al Gilman <Alfred.S.Gilman@IEEE.org>
Date: Mon, 10 Dec 2007 11:17:18 -0500
Message-Id: <p06110425c381e22f5f5d@[192.168.1.102]>
To: Erik Wilde <dret@berkeley.edu>, uri@w3.org

At 12:12 PM -0800 8 12 2007, Erik Wilde wrote:
>... i am still wondering whether there is some general rule of how 
>the namespace question should be handled in a uri scheme.

To the best of my knowledge, no.

The general practice is that the schemes themselves form a 
first-order partitioning of
the space of URI, but that any practices or principles as to 
subdivision beyond that
is delegated to the schemes.  There are some re-used substructures 
but no global
policy.

And there is general back-pressure against coining new schemes.

<quote
cite="http://www.w3.org/TR/webarch/#URI-scheme">

   Good practice: Reuse URI schemes

A specification SHOULD reuse an existing URI scheme (rather than
create a new one) when it provides the desired properties of
identifiers and their relation to resources.

</quote>

I would suggest you review what you can say in the ldap: scheme for a 
URI encoding that
is all there, and if you are not satisfied with that consider 
registering a subspace in
the info: scheme.

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

Short answer:

<place name> is_a 'where'

.. where
   is_a is the Booch generic/specific relationship in the sense from 
specific to generic
  'where' is the item in the Journalist's creed of what, when, where 
and sometimes why/how

That would cue Mike's schema-reconciliation engine to seek inferences 
about where
in WGS84 terms this <place name> actually means.

And you can do that just fine with microformats.  Go for it.

No reason to assign a global ID for private info.

Compare with the discussions of how the html4:html.profile list of URIs can add
information context for those who need it.

http://www.w3.org/2001/tag/issues.html#standardizedFieldValues-51
http://www.w3.org/2007/11/07-TechPlenAgenda.html#uri

In your case, "South Hall" would be text content in the HTML.  It 
would be wrapped
in something that cues this is a placename.  Could be as simple as a 
token present
in the @class set of tokens.  Your crowd-sourced vocabulary would be in the
notation of your choice and would be bound to this attribute value by 
a selector in a
buffer doc that is cited in the @profile.

This buffer doc is what I call an 'interpretation sheet.'  Compare with RDDL.
http://lists.w3.org/Archives/Public/public-ws-addressing/2005Apr/0015.html

This is where microformats are at the moment: most people process the info
from the short name.  Few need the backup.  But the full drill is 
still to publish
the backup to avoid future problems as people start to use the design pattern
more.

So your friends who know your habits will process the name anyway from the
short name.  They don't need to be told that it is a place. Only the people who
need more help decoding the short name need the information that it is a place
to be available in metadata.  [and scheme rules are metadata in this sense].

[new topic]

Why there's value in not just letting them coin URIs for undocumented 
placenames:

Contextualized use, yes.  But this is a short-names issue.

The problem with thinking a partition is the answer is that the set
of people who will decode Sproul Hall as a Berkeley place is much
broader than the comparable subset for most other Berkeley places.
There's no bright line around the speaker group, nor around the
audience to whom you want to mention these places.

People use short-name a.k.a. terse signs when they think they
are addressing those who already know the context.

Maybe it's the fact that I live in Accessibility these days, where
you are constantly pushing authors to take just a moment to capture a
little more context or other information for the unanticipated
audience member. So my kneejerk is to get people who want to use
short names to give some idea of the context in which they think the
decoding of that short name would be unique.

This is not a markup-language context.  It is a places context.  Just
an "in <foo>" or "near <bar>" where <foo> or <bar> is findable in
some database that has WGS84 convertibility.

Don't give them a global, but in the global view opaque atomic code
point for the short-name _label_ of the place; make the _place_ the
subject of discussion and the label a property.

Your examples are not atomic place names.  "the Korean place where
I eat after [swimming at] lunch" is a structured query.  It is a place,
OK, but it is identified by traits:  it serves food.  it serves Korean food.
It is open after lunch.  [by inference from the narrative] it is convenient
to the aforementioned pool.

There is an audience for simply the fact that there is a place serving
food in the vicinity.  There will be more interest aroused among a smaller
audience if we add the fact that it is Korean food.  And so on.  Any
subset of the traits that you used to identify the place is of interest
to some querying audience.

The things your intimates recognize are not names, they are structured
utterances.  If we deconstruct those utterances, we can see that they
are composed of more-broadly-understood concepts.

This is not RDF-think, it's as old as CODASYL and Codd&Date.

RDF is just underkill in tooling up relationships.  It's a bad design for
a good technology segment.

Viewing your insider utterances with an eye to spotting reusable
relationship concepts is work, but yields a higher-value resource.

.. end of rant.

Al

>
>>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 Monday, 10 December 2007 16:17:38 UTC

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