OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

tm-pubsubj-comment message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

Subject: Re: [tm-pubsubj-comment] More grumbling

Answer to part of the grumbling only :)

*Lars Marius
> This is a critique of the current strawman proposal, in order to get
> what I consider to be the issues with it onto the table where they can
> be discussed.
>   "In order to facilitate the automated discovery of PSI sets,
>   publishers are recommended as far as possible to use URLs that
>   contain the token 'psi', for example as a component of the hostname
>   or path [...]"
> Here it is unclear what "automated discovery" is supposed to mean.
> Discovery of what, by what means, and in what context?

I suppose that means capacity for search engines to distinguish the "signal" of PSIs among
"noise" of billions of ordinary URIs, which is something like SETI search. What should we
look for? I agree it has to be more explicit.

> In any case, it is very clear that the appearance of the string "psi"
> in a URI is by no means sufficient to establish that the URI refers to
> a published subject. When doing a simple Google search for "PSI" out
> of the first 10 URIs returned, 9 contain that token...

Indeed. We should be less fuzzy on that to reduice the noise. If we recommend the use of
the token "psi", we maybe should recommend a more precise use of it, like its position in
the URI string, and maybe recommend a whole standard structure like:

> I think if we can specify clearly what it is we want to achieve, we
> can do so by different means, but that requires us to be clear about
> what it is we want to do.

IMO what we want to achieve is to allow search engines - and also humans - to distinguish
with the less noise possible URIs who are declared PSIs from those who are not. Of course
we will not get rid of all the noise, but we can put it down to a reasonable level by
recommending a given URI structure.

>   "In order to make PS identifiers easier to remember and use,
>   publishers are advised to consider using human interpretable strings
>   rather than numeric or other values that are not immediately
>   interpretable by humans, provided that this does not otherwise
>   compromise the stability, longevity, acceptability, or usability of
>   the PSI."
> My problem with this recommendation is that it is self-contradictory.

Could you explain exactly where you think the contradiction lies?

> Steve's and Bernard's response to that was that in some cases you will
> know up front that this is not going to be a problem. There are two
> responses to that.

> The first is that if that were true it is still a problem that this
> paragraph provides too little guidance on how to tell those cases
> apart. To be really effective we should provide more guidance.

I think the example should show that better than any abstract prose here.

> The second is that I would not trust myself to be able to distinguish
> between such cases. Do you think the people who chose "ROM" as the
> identifier for Romania knew that the word meant gypsy, that it would
> appear on people's passwords in big yellow letters, and that the
> Romanians would object to this?

Of course. There again, it is not a clear-cut solution. Humans to know for sure what the
subject is have to retrieve the Subject Indicator, but the URI syntax could provide hints,
help for search and reminder. The same way you are better off to have Ontopia's web site
under www.ontopia.net that under www.tx4863m.biz, and my e-mail has better be
bernard.vatant@mondeca.com than ber456@yahoo.fr . No more, no less.

> In computer science it is held to be common knowledge that one should
> not create identifiers that have significance to humans, precisely for
> this reason.

Yes, but all the Web story tends to question that, with domain names and e-mail adresses.
And it does not work that bad.


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

Powered by eList eXpress LLC