RE: [tm-pubsubj-comment] Pub Sub working draft comments

[Kal Ahmed <kal@techquila.com>]

On Wed, 2003-03-12 at 23:13, Bernard Vatant wrote:
>=20
> Hello Kal
>=20
> Thanks for your feedback.
>=20
> | Section 2.3
> |=20
> | I understand where this section is coming from, but the argument =
is a
> | little too simplistic.
> |=20
> | On the web, URIs do not necessarily address a resource, they migh=
t
> also
> | address a service, but the representation retrieved by derefernci=
ng
> the
> | URI is not the service, merely the results of the service perform=
ing
> | some processing. c.f.
> | http://www.google.com/search?hl=3Den&ie=3DUTF-8&oe=3DUTF-8&q=3Dto=
picmaps
> |=20
> | The resource is not "topicmaps" (which is what I typed into the s=
earch
> | box), nor is it Google, but it is the result of asking Google for
> pages
> | about "topicmaps"
>=20
> The recommendation does not say that *any* URI adresses a
> well-identified stable resource, even less a subject indicator. All=
 the
> point of the recommendation is indeed to specify under which condit=
ions
> a URI can be used as a subject address or a subject identifier. Cle=
arly,
> the example you give would not be considered a conformant subject
> identifier, because whatever you retrieve there is all but a good
> subject indicator.
>=20
> | I guess that my concern is that not all addresses are addressable
> | resources, because addresses are also used as gateways to service=
s. I
> do
> | not think that this is something that needs to covered in great
> detail,
> | but I think that the section would be stronger if it acknowledged=
 that
> | other uses of URIs are possible and that these fall outside the s=
cope
> of
> | the discussion.
>=20
> The recommendation does not pretend to cover all possible uses of U=
RIs.
> It's not the point. It simply says: if you want to identify a resou=
rce,
> or a subject, you can (should) use a URI, and that's the way to do =
both.
>=20
>=20

Agreed. That is completely clear in my mind, as it was when I started
reading the recommendation. But in my reading of the document I did n=
ot
see that point made clearly enough. It doesn't confuse me, but it may
confuse others.

> | Section 2.4.2
> |=20
> | "if the identity of two topics is established by subject indicato=
rs
> that
> | have the same address, they should be regarded as representing th=
e
> same
> | subject."
> |=20
> | How are addresses compared ? Straightforward string comparison is=
 not
> | necessarily a guaruntee that two addresses are not the same:
> | http://www.techquila.com/ and http://www.techquila.com/index.html
> | address the same resource because of server-side processing. Simi=
larly
> | typing techquila.com into my browser gets me the same resource be=
cause
> | of a combination of client-side and server-side processing.
>=20
> Kal, I think you get mixed-up here. When the strings are strictly
> *equal*, the resource is the same. That we are sure of. Full stop. =
When
> the strings are not equal, nobody knows. That's what the last
> Recommendation #6, which IMO should become a requirement, is about.=
 The
> subject indicator should (must) state which string (and only one) i=
s to
> be used as its subject identifier. If you want
> "http://www.techquila.com/index.html" to identify the subject
> "techquila" then it has to be stated in the subject indicator that =
you
> retrieve here. And http://www.techquila.com/ will not be the correc=
t
> identifier for this PSI, even if it address the same resource.=20
>
> IOW, a subject identifier is a URI is a string, and not all possibl=
e
> different strings addressing the same resource.
>
Then that should be made clear. You should also be aware that this is
contrary to the (normative) XTM 1.0 section F. Again, I think that th=
is
is a potential source of confusion.

I am not saying that your approach is wrong. Lexical comparison is in
many ways far more robust than URI comparison - mainly because it can=
 be
done by ordinary mortals without reference to an RFC. But you must be
aware that XTM 1.0 F.2.2 explicitly says that:
http://www.Techquila.com/psi/foo#bar is equal to
http://www.techquila.com/psi/foo#bar and not equal to
http://www.Techquila.com/PSI/foo#bar

> That does not prevent from having several PSIs developed by differe=
nt
> publishers for the same subject, which is an orthogonal issue.
>=20
Absolutely, and that is not my point. My point is the comparison of P=
SI
URIs. Are you using RFC 2396 as recommended in XTM 1.0 or lexical
comparison.

> | XTM 1.0 section F.2.2 expresses the rules which establish when tw=
o
> URIs
> | are to be considered equal (by chickening out and pointing to the
> | relevant RFCs ;-). Either this specification should do the same, =
or
> else
> | it should include sufficient words to make it clear that address
> | comparison is not necesarily a straight-forward lexical compariso=
n and
> | that the comparison mechanism should be dictated by the subject
> | indicator address notation.
>=20
> I'm afraid I don't catch you here. I would gladly hear Lars Marius =
on
> that one.
>=20

A brief skim through RFC 2396 should explain my position - hopefully =
the
additional examples given above should help clarify matters too.

> | Section 3.1.2
> |=20
> | If the URN could be "resolved" by looking it up in a book, would =
that
> | meet requirement 2 ? If to "resolve" the URN you had to email the
> | "Keeper Of The Definitions", would that meet the requirement ?
>=20
> I would say no and no. But those are clearly borderline examples.
> Depends on the flexibility you gaive to the notion of
> "network-retrievable" ...
>=20
> | IMHO, the resolution mechanism is only going to be useful if it i=
s
> known
> | to those using the PSI. So I would change this requirement to
> something
> | a little stronger:
> |=20
> | "A Published Subject Identifier must be resolve to a
> human-interpretable
> | Published Subject Indicator using a resolution mechanism known to=
 and
> | accessible by the intended audience of the Published Subject
> | Identifier."
>=20
> You are right "en principe", but that is can of worms opening and d=
oes
> not sy much. Too many fuzzy terms here : "known" "accessible" "inte=
nded"
> ...
>=20
I think that the notion of the "intended audience" of a PSI is an
important one, even if the notion is somewhat fuzzy. If I publish a s=
et
of PSIs within an organisation and the indicators are kept on a web
server behind my corporate firewall, that is fine. But I believe that=
 I
could not claim that they were published to an audience consisting of
people outside my organisation unless the indicators exist on a
web-server accessible to the public.

In other words, if the reader of a PSIdentifer cannot get the
PSIndicator, then the PSI(s) both lose their status as Published.

> | BTW, "a human-interpretable" sounds better to me than "an
> | human-interpretable", but don't ask a Brummy for advice on Englis=
h
> (c.f.
> | http://www.virtualgaz.co.uk/gazzapage.htm)
>=20
> Hmmm, maybe that is a vestige of ye olde frenchie editor, not corre=
cted
> by current editor, like "an URI". Now I know better, thanks to Dr P=
epper
> :))
> =20
> | Section 3.2
> |=20
> | "Human-readable" should probably be defined more clearly. e.g. I =
would
> | suggest that comments in an HTML page are not human-readable in t=
he
> | sense that they would not be displayed in the application which
> | implements the resolution mechanism. Also, human-readable English=
 is
> not
> | human-readable. Again, I think that the concept of the audience o=
f the
> | PSIndicator needs to be considered here.
>=20
> Well, the audience of a PSI can't be decreted nor even defined.

I think that it can for many applications - especially those within a=
n
organisation or a community.=20

> Like for
> anything else, the audience will be made by those who find it usefu=
l
> because they understand it and find it relevant.

I would argue that we already have many (XML) vocabularies that are
meaningful only to a subset of the world, and usually one that is
tightly defined by some community of practice. For example, HL7 messa=
ges
are really unintelligible to anyone outside the realm of IT for
Healthcare, but within that community of practice they are a well
understood lingua-franca for information interchange. The same should=
 be
true of good PSIs.

> Japanese folks will use
> PSIs that provide definitions in Japanese language for concepts
> understandable by Japanese, I guess. And I remember having a
> conversation with Patrick Durusau in Montr=C3=A9al, where he said w=
isely that
> PSIs for Biblical subjects certainly will not be relevant - not to =
say
> readable - by people who do not care about the Bible, and well, tha=
t's
> fine.=20
>=20

I don't disagree with you at all. But the notion of the "audience" is
what is at work here, and that is something that, IMHO, is missing fr=
om
the recommendation as it stands. If you think that it might be
worthwhile, I shall try and put aside some time today to scribble dow=
n a
paragraph or two as a proposal for the editors.

Cheers,

Kal



----------------------------------------------------------------
To subscribe or unsubscribe from this elist use the subscription
manager: <http://lists.oasis-open.org/ob/adm.pl>