[
Lists Home |
Date Index |
Thread Index
]
How is this any different than the already well established
understanding that a URI references a single resource
that may have multiple representations? I think the
relationship is better stated as there being a many-to-one
relationship between URI and Resource, and a one-to-many
relationship between Resource and Representation.
Effectively there is a many-to-many between URI and
Representation, but that's a much different thing
than saying theres a many-to-many between URI and
Resource.
-----Original Message-----
From: Simon St.Laurent [mailto:simonstl@simonstl.com]
Sent: Thursday, January 23, 2003 2:11 PM
To: xml-dev@lists.xml.org
Subject: [xml-dev] many-to-many
Bill de hÓra posted something on www-tag that's very much worth
contemplating, even if you don't like it.
http://lists.w3.org/Archives/Public/www-tag/2003Jan/0301.html
The juicy bit is:
>I offer an opinion. The relationship between URIs and things is many
>to many. One URI will be used to denote many things. A thing will be
>denoted by many URIs.
>
>I offer a rationale for this opinion. It's preferable to constrain
>the relationship to one to many, as this results in simpler,
>deterministic software. However I believe the notion that a URI only
>ever identifies one thing, however appealing, is fictitious, and an
>shackle on the semantic web that will lead to unscalable systems and
>fringe benefits, in much the same way backlinking sidelined
>hypertext until the web was invented without the backlinking
>constraint. the many to one relationship will not hold, nor is
>manageable across the number of authorities the web encapsulates,
>leading to ambiguous and outright inconsistent data sets shared
>across a gloabl system that is by definition not architected to be
>resilient to inconsistency. Hence I encourage to TAG to advise the
>relationship is many to many.
At first I thought this was off the wall, and it may yet prove so. On
the other hand, I didn't have much difficulty coming up with cases where
this makes sense, and they weren't necessarily perverse.
Even in relatively simple load-balancing HTTP systems, one URI may
itself correspond to multiple interior resources which may or may not be
in sync. In XML, a particular URI+localName may correspond to semantics
which vary - and reasonably so - with context.
While I've been spending most of my time in the URI universe trying to
nail down as much as possible, because certainty makes writing reliable
software far easier, there's some clear beauty and even utility in this
notion that ambiguity is here to stay, and that we'd do well to get rid
of the fiction of a singular mapping. That at least has the merit of
forcing us to explore how we expect these mappings to work, and
acknowledge the prospect that different mappings exist for different
contexts.
Bill also wrote, in reply to Tim Bray:
>> Clearly, a resource whose identification is
>> muddified or inconsistent is less useful, and makes the Web less
useful.
>
>Only in a binary web. In a probabilistic web, it's less of an issue.
(http://lists.w3.org/Archives/Public/www-tag/2003Jan/0302.html)
It seems that perhaps we already live in a probabilistic web, and should
focus on making ourselves comfortable here.
For XML, I think that's going to mean thinking about namespaces yet
again, and in particular starting to think hard about the implications
of mixing vocabularies defined in different namespaces. Modularization
gets pretty nasty as we try to build schemas that can support components
from multiple namespaces in different contexts.
Figuring out how to address things like how elements in one namespace
can create a context that limits elements in another namespace is
getting more important as more and more mixing takes place. It may be
time to shed the notion that 'owning' a namespace identifier lets you
make definitive statements about the components defined using that
identifier, and start thinking about the prospect that resources can
have relationships which change each other fundamentally through
context.
URIs still make my head hurt, and this isn't likely to cut down on the
need for aspirin, but at least it feels like a new doorway in the
never-ending URI (or namespace!) maze.
--
Simon St.Laurent
Ring around the content, a pocket full of brackets
Errors, errors, all fall down!
http://simonstl.com -- http://monasticxml.org
-----------------------------------------------------------------
The xml-dev list is sponsored by XML.org <http://www.xml.org>, an
initiative of OASIS <http://www.oasis-open.org>
The list archives are at http://lists.xml.org/archives/xml-dev/
To subscribe or unsubscribe from this list use the subscription
manager: <http://lists.xml.org/ob/adm.pl>
|
