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

Lars, can you point me at the 'current strawman proposal' you're
referring to and associated discussions?  I think i missed a whole bunch
of context... 

From your critique of this proposal it seems clear that various
discussions are taking place outside of
tm-pubsubj-comment@lists.oasis-open.org ... If there are additional
public forums where this kind of work is being discussed can you point
me to these?

Sigh... From your critique as well (all of which seem sensible) it
seems  clear that TopicMap and RDF/XML are traveling down (again) very
similar paths wrt deployment.  I for one still think there is huge
benifit in collaboration and increasingly frustrated by the lack of

That being said, i still am not sure what the best way is to proceed on
this front. Perhaps the status quo with independently developed
activities is all that we can manage, however to see such duplicated
effort for similar and overlapping goals I find extremely unfortunate.

I would welcome suggestions on practical steps to help address this

eric miller                              http://www.w3.org/people/em/
semantic web activity lead               http://www.w3.org/2001/sw/
w3c world wide web consortium            http://www.w3.org/

On Tue, 2002-06-25 at 15:52, Lars Marius Garshol wrote:
> 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?
> 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...
> 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.
>   "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.
> 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.
> 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?
> 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.
> I would very much prefer that we just leave this out.
>   "URNs that conform to registered and approved URN schemes may be
>   used as PS identifiers in conformance with this Technical
>   Report. However, publishers are recommended to consider the
>   implications for usability if there is no well-defined resolution
>   mechanism for the URN scheme."
> This is bound up with a SAM issue, actually. See
>   <URL: http://www.ontopia.net/omnigator/models/topic_complete.jsp?tm=tm-standards.xtm&id=locator-reference >
> Basically, what this issue is about is that the [subject address] and
> [subject indicator] may, as things now stand, contain locators that
> refer to something that is not an information resource. If that
> happens the heuristics meant to be provided by these properties no
> longer work as intended.
> So we need to consider what to do about this. 
> At the moment I don't really see why we would want to allow URNs.
> Aren't PSIs supposed to have a subject indicator resource somewhere?
> If so, why do we want to allow URIs that don't resolve?
>   <meta lang="en, fr, jp"/>
> This is incorrect HTML. In fact, there's no good way to specify this
> in HTML, but then I am not sure we have any need to. I would let it
> be. (Yes, there is a lang attribute, but it only supports a single
> value.)
>   <link rel="topicmap" href="http://psi.fruits.org/fruits.xtm";
>         type="text/xtm">
> This raises several different issues. The first is what "rel" values
> we should use. Do we need different values for RDF and topic maps? How
> do we distinguish different topic map syntaxes? 
> The MIME type given here is not valid, since it is not registered. The
> question is, should we try to register one for XTM? I am not sure
> whether it will be accepted (and it won't help for HyTM and LTM), but
> it seems that it could be done without too much work. I volunteer to
> do it, if we decide that we want to.
> See also the relevant section of HTML 4.01:
>   <URL: http://www.w3.org/TR/html401/types.html#type-links >
> (Note the stuff about profiles.)
> Well, that should be enough grumbling for one email.
> -- 
> Lars Marius Garshol, Ontopian         <URL: http://www.ontopia.net >
> ISO SC34/WG3, OASIS GeoLang TC        <URL: http://www.garshol.priv.no >
> ----------------------------------------------------------------
> To subscribe or unsubscribe from this elist use the subscription
> manager: <http://lists.oasis-open.org/ob/adm.pl>

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

Powered by eList eXpress LLC