[
Lists Home |
Date Index |
Thread Index
]
Mike Brown writes:
> I can see how using a URI for its syntax and not its semantics
> undermines interoperability.
I'm not quite sure how you're distinguishing syntax and semantics here,
but then I've never been clear how exactly namespaces use URI semantics,
if at all.
> But I don't see how URLs fix that.
URLs don't fix much except that you can get an answer of some kind.
Whether that answer helps you or not is a different question. The
notion of URIs takes away the "give me an answer" and leaves us with a
pile of characters and few rules for determining even as simple a thing
as "are these the same identifier?", never mind "do these identify the
same resource?".
> If I
> want an identifier, it might be just as advantageous as it is harmful
> to use an identifier that might also be usable in other contexts, be
> they temporal or systematic.
Sure. And if you want to share those identifiers, what would your
expectations be? Do you like the roughly-shared understandings that
URLs provide, or would you prefer the looser approach that URIs offer,
even when the identifier in question is also a URL?
> > The philosophy behind URIs seems designed to ward off questions
> > rather than promote interoperability
>
> Ambiguity == interoperability. You seem to be supporting your own
> argument.
Ambiguity at this level promotes interoperability? I'm sorry, but I
either have no idea whatsoever what you're saying or disagree
fundamentally.
I'm perfectly happy to have local interpretations of identifiers, but
not very happy about having no general notion about what these
identifiers are about.
(And supporting my own argument hardly sounds like a bad idea, but I
don't think that's what you meant to say.)
> There is deliberate ambiguity in how we use URIs. There is ambiguity
> inherited from the loose definition of resources, as well as from the
> lack of constraints on degrees of identity. All this looseness
> promotes interoperability (e.g., "whatever wants to call itself
> 'http://example.com/spam' today is spam to me, good enough").
And I find that useless and remarkably confusing on the days when I deal
with users, myself included, expect http://example.com/spam to have a
meaning beyond "because I'm an idiot, I chose a string of characters as
an identifier which most people will assume, because of its syntactic
convention, has a completely different meaning than the way I'm using
it."
> I don't see ambiguity stemming from the fact that the URIs are
> identifiers, or from whether they take the form of names or locators
> (which seems to be your argument). So I don't see URIs as the
> problem. The philosophy behind them doesn't seem to be suspect. Maybe
> I choose to use them in less interoperable ways (e.g., namespace
> identifiers, or other non-dereferenceable resource names).
So you're happy with the disconnected syllogism that a resource is
something identifiable by a URI, and an identifier is something that
identifies a resource?
Derrida is more helpful than that pile of nothing.
> I also think the whole argument is pointless. We could constrain
> namespace identifiers to be ISO 8601 dates, and it wouldn't make
> legitimate date strings any less meaningful, usable, or interoperable.
But it would lead to the same kinds of confusion that the current
approach offers, minus the possible advantages of a diverse and lightly
'owned' set of identifiers.
Maybe a better question would ask which subset of identifiers is most
useful for namespaces, and why? If dereferencing was important, URLs
would be good. If uniqueneness was important, URNs would be good.
Instead the W3C drops the whole pile of URIs on the floor with scarcely
an explanation, leaving thousands of people confused on a regular basis.
> > God knows I'm tired of talking about this stuff,
>
> Apparently you aren't! ;)
No, I'm quite definitely tired. Unfortunately, no one else seems to
have the patience needed to push back on this bizarre mash of
energy-wasting nonsense most frequently identified as "URIs".
--
Simon St.Laurent
Ring around the content, a pocket full of brackets
Errors, errors, all fall down!
http://simonstl.com
|
