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

[Bernard Vatant <bernard.vatant@mondeca.com>]

Hello Kal

Thanks for your feedback.

| Section 2.3
| 
| I understand where this section is coming from, but the argument is a
| little too simplistic.
| 
| On the web, URIs do not necessarily address a resource, they might
also
| address a service, but the representation retrieved by dereferncing
the
| URI is not the service, merely the results of the service performing
| some processing. c.f.
| http://www.google.com/search?hl=en&ie=UTF-8&oe=UTF-8&q=topicmaps
| 
| The resource is not "topicmaps" (which is what I typed into the search
| box), nor is it Google, but it is the result of asking Google for
pages
| about "topicmaps"

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 conditions
a URI can be used as a subject address or a subject identifier. Clearly,
the example you give would not be considered a conformant subject
identifier, because whatever you retrieve there is all but a good
subject indicator.

| I guess that my concern is that not all addresses are addressable
| resources, because addresses are also used as gateways to services. 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 scope
of
| the discussion.

The recommendation does not pretend to cover all possible uses of URIs.
It's not the point. It simply says: if you want to identify a resource,
or a subject, you can (should) use a URI, and that's the way to do both.


| Section 2.4.2
| 
| "if the identity of two topics is established by subject indicators
that
| have the same address, they should be regarded as representing the
same
| subject."
| 
| 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. Similarly
| typing techquila.com into my browser gets me the same resource because
| of a combination of client-side and server-side processing.

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) is 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 correct
identifier for this PSI, even if it address the same resource. 

IOW, a subject identifier is a URI is a string, and not all possible
different strings addressing the same resource.

That does not prevent from having several PSIs developed by different
publishers for the same subject, which is an orthogonal issue.

| XTM 1.0 section F.2.2 expresses the rules which establish when two
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 comparison and
| that the comparison mechanism should be dictated by the subject
| indicator address notation.

I'm afraid I don't catch you here. I would gladly hear Lars Marius on
that one.

| Section 3.1.2
| 
| 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 ?

I would say no and no. But those are clearly borderline examples.
Depends on the flexibility you gaive to the notion of
"network-retrievable" ...

| IMHO, the resolution mechanism is only going to be useful if it is
known
| to those using the PSI. So I would change this requirement to
something
| a little stronger:
| 
| "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."

You are right "en principe", but that is can of worms opening and does
not sy much. Too many fuzzy terms here : "known" "accessible" "intended"
...

| BTW, "a human-interpretable" sounds better to me than "an
| human-interpretable", but don't ask a Brummy for advice on English
(c.f.
| http://www.virtualgaz.co.uk/gazzapage.htm)

Hmmm, maybe that is a vestige of ye olde frenchie editor, not corrected
by current editor, like "an URI". Now I know better, thanks to Dr Pepper
:))
 
| Section 3.2
| 
| "Human-readable" should probably be defined more clearly. e.g. I would
| suggest that comments in an HTML page are not human-readable in the
| 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 of the
| PSIndicator needs to be considered here.

Well, the audience of a PSI can't be decreted nor even defined. Like for
anything else, the audience will be made by those who find it useful
because they understand it and find it relevant. 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éal, where he said wisely 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, that's
fine. 

Bernard



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