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

 


Help: OASIS Mailing Lists Help | MarkMail Help

tm-pubsubj message

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


Subject: Re: [tm-pubsubj] Points from psdoc post 29/01


Peter

>     How do topic maps deal with subjects? First they represent subjects
>     formally as abstract "topics". In XTM documents, topics are
>     represented by a <topic> XML element. A topic should represent an
>     unique, well-defined, non-ambiguous subject.
>                                         *******
> This equates 1 topic with 1 subject, whereas the rest of the text talks
> about "topics" and "subjects" (plural) which may confuse the reader.

Exact. Using singular form all along would be clearer. I will correct that.

> 4.
>     A published subjects documentation shall include a formal statement
>     from its publisher, expliciting its conformance to this
>     recommendation, and its intention to maintain the documentation
>     trustable, and the PSIs stable.

BTW it should be "published subject documentation set" ... that one escaped the rewording.

> Having just had a discussion with a colleague about the venality of
> publishers :-) I wonder if Requirements #4 is enough to stop the
> indiscriminate publisher from simply lying about the trustworthiness and
> stability? Once this takes off and the marketing people get into the
> act, will we see XTM spam masquerading as useful information?

I don't think there is a real risk here. Like everywhere else, trust in that matter will
be a bootstrapping process.
In fact, I figure efficient use of PSIs will occur not in the open wild web, but inside
communities of practice/knowledge, big entreprises intranet portals etc. For PSIs to make
sense, their semantics are somehow to be shared by their community of users. Very
technical PSIs will be published by well-identified publishers for well-identified
communities of users. Having garbage popping around is likely, but I don't figure what
would be the business case for them.

> 4.3.2: is it our job to go as far as writing a *canonical* DTD/schema
> for PSIs (as hinted at in Requirements #3), like Bernard's pubsubj.dtd?

Nope. We are now over that stage of reflection. As said yesterday, our job is to say: "If
you use such syntax/format, we recommend such structure". The DTD I provided was in that
spirit (if you publish XML subject indicators, they could look like that). We are moving
now towards a "cross-syntax meta-model".

Thanks for your input.

Bernard



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


Powered by eList eXpress LLC