W3C home > Mailing lists > Public > www-tag@w3.org > October 2003

RE: Arch Doc: 26 September 2003 Editor's Draft (review of someterms)

From: Olivier Fehr <Olivier.Fehr@ofehr.com>
Date: Wed, 1 Oct 2003 12:34:51 +0200
Message-ID: <F92F63FC00C0AD4D88BECB3BCF90734B19F1@coyote.ofehr.com>
To: "Ian B. Jacobs" <ij@w3.org>
Cc: "Dan Connolly" <connolly@w3.org>, <www-tag@w3.org>


-----Original Message-----
From: Ian B. Jacobs [mailto:ij@w3.org] 
Sent: mardi, 30. septembre 2003 23:51
To: Olivier Fehr
Cc: Dan Connolly; www-tag@w3.org

On Mon, 2003-09-29 at 17:02, Olivier Fehr wrote:
> Abstract
> <quote>
> ...of Web resources that are interconnected via URIs..
> </quote>
> ->probably better to say 'can be interconnected', as they may exist in
> the same information space without any relation to each other.

I propose to change "that are" to ", which are".
[Olivier says] Not sure what the underlying concept is that makes you
say that Web resources _are_ interconnected. In what sense?

> 2.1 Comparing Identifiers
> <quote>
> ..,it is generally not possible to be sure that two URIs that are not
> equivalent identify different resources.
> </quote>
> This follows from 'Web architecture does not constrain resources...'
> 2.

Does it? What if the Web architecture allowed us to use more than
one URI to identify a resource, but in all cases it was possible
to determine that from examining the URIs alone. I don't think
the part about "generally not possible to be sure" is necessarily
implied by the sentence you are referring to.
[Olivier says] To be more specific, if I accept that I do not have any
authority over www.w3.org, then I cannot rely on any assumption I make
about www.w3.org/whatever unless the authority describes somehow what
/whatever is, but then I no longer have to make any assumption.
My point is, if there is no central authority that can determine what
www.w3.org/whatever is supposed to be and how it is supposed to look
like then we must rely on the 'decentralized' authorities.
If I understand, your approach would be somehow defining/mandating the
meaning of /whatever centrally? 

> <quote>
> Agents should not assume...
> /Oaxaca and
> /Oaxaca identify the same resource,...
> Thus, the parties responsible for weather.example.com should not
> </quote>
> I don't think the 'thus' is necessarily correct, as the responsible
> weather.example.com can simple determine, i.e. stipulate that both
> reference the same, whereas a agent is not free to assume that
> equivalence lacking a clear statement of equivalence from the
> responsible authority.

I'm not sure I've understood your point, since you seem to
be agreeing with the point of the paragraph.[Olivier says] 

[Olivier says] I am getting at is that the agent is not free to assume
the meaning of, what is behind /whatever, even if it seems obvious (this
is seen from the view of the agent). From the view of the authority, why
should the authority not be able to declare, for example, /Whatever and
/Whatever equal. So I can't see why ...the responsible for ... should
not use... 

> 2.2 URI Opacity
> 'Good practice'
> Somehow confirms my believe above
> <quote>
> The example URI used in ... suggests...
> On the other hand, the "mailto"...
> </quote>
> As you say, the normative specification makes the difference. By
> assuming that a certain type of resource can be constructed by
> the parts of an URI, an agent might well end up with something
> completely irrelevant to her/him/it.

I'm not sure if you are proposing a specific change here.
[Olivier says] The agent should (be able to) rely on the authority's
definition what a resource under its authority is about. Obviously, they
will need to have that description to be available in a standard format
adhering to a defined vocabulary, however if you standardize this
vocabulary, without possibility for extension, then authority is no
longer 'in control'. 
In short, is the goal to mandate via a standard a complete vocabulary or
a just rules how to construct one? In the later case the authority would
probably make changes which the agent may not be able to deal with. I
gues we would have to live with this coupling, unless the agent is able
to adjust itself to new vabularies 'on-the-fly', e.g. by interpreting
the authorities description according to some rules that may possible be
supplied with the description. Makes the agent a behave more like a
human, I think...

> <quote>
> Editor's note...metadataInURI-31...
> </quote> 
> For web services there is a WSD(L), for other content there is no such
> thing as a WCD (Web Content Description), so usually there is now way
> knowing what is behind the starting URI, e.g. http://www.w3.org.

I think there is RDF work as well; see the sections on future
work for identifiers.
[Olivier says] Will do.

> 2.3. URI Schemes
> <quote>
> If the motivation behind registering a new scheme is to allow an agent
> to launch...such dispatching can be achieved by registering...
> </quote>
> While I agree, I would also add this might be an alternative if some
> patent holders have their way...

> <quote>
> The user of unregistered URI schemes is discouraged...
> </quote>
> Yes. After all an agent would have to support this scheme, thus making
> that approach unsuitable for broad Internet use. While I could do
> something like this internally, I would be building something
> proprietary which shouldn't be done except for very valid business
> reasons, but then I can register it...


> 2.5.2. Safe Interaction
> This seems to be a very limited definition of 'safe' from the agent's
> point of view. Seems more like a concept of liability or obligation...

I think that's how "safe" is being used in the relevant RFCs.
[Olivier says] OK, I am still reading up on the relevant RFCs, so it's
possible I've missed that meaning.

> I think I stop here. It's getting rather long (and late)

Thank you for your comments, Olivier.
[Olivier says] When I care about something, I'll try to make a

 - Ian

Ian Jacobs (ij@w3.org)   http://www.w3.org/People/Jacobs
Tel:                     +1 718 260-9447
Received on Wednesday, 1 October 2003 06:35:20 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 15:32:40 UTC