Re: [tm-pubsubj-comment] Fwd : On "prohibition" of XTM and URNs

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

Eric, Murray

Some preliminaries before answering specific parts of your debate.

I would like to keep this forum - and myself - as far as possible of anything like
*yet-another-TopicMaps-RDF-war*
This forum is not the place for it - if there is a place fit for it anywhere I don't
figure actually :))

Let me make some points again, I think they reflect the TC consensus, and if not, please
folks correct me.

Even if the PSI concept is born inside the Topic Map paradigm, it has to somehow become
adult. It has to become quite clear to eveybody that PSIs are not Topic Maps side orders,
but main course for all those who care about identification of subjects in systems that
involve both machines and humans, and need interagreement between all of those. And that
goes beyond Topic Maps and beyond RDF and beyond the Semantic Web or any other specific
technology. Or more exactly it's orthogonal to all of them.

So we (meaning here : the TC) will not fight any more on what will be the recommended
syntax(es) or metadata types for PSIs, but on what would be the best practice when using
such and such syntax or metadata format currently widely adopted. Which format is the best
we don't care. Which is here to say we don't care.

So if people want to express PSI with XTM, fine : bring examples, let's figure best
practices.
If people want to express PSI with RDF, fine : bring examples, let's figure best
practices.

If people don't care about either of the above (and they are perfectly entitled to do so),
fine : bring examples in XHTML, or even plain vanilla HTML. Or whatever format will pop up
in the years to come.

Now to some specific points

*Murray
> > I realize I have a completely different set of priorities than
> > some, but if the topic map community doesn't have PSI publishing
> > ability soon, there simply will never be the public sharing of
> > topic maps within a reasonable amount of time, and people may
> > move on to something else given no standards for participating.

From a "TM vendor" viewpoint, maybe I have also different priorities. I must say that
public sharing of Topic Maps has not been seen as an urgent problem - if a problem at
all - for any of early industry adopters we've met. To be crude, I would say they really
*don't care*. Customers we have are very happy with TM support for their intranets, well
hidden behind strong firewalls, because they deal with very confidential subjects to be
hidden for competition or security purposes. They are more focused on the power of TM for
semantic federation of their closed universe than on subject identification on the public
web space.

Mary Nishikawa has presented in Montréal a very convincing use case for PSIs in Oil
Services at Schlumberger. This is very far from all Semantic Web dreams on one side, and
Global Knowledge Interchange dreams on the other side. And I was very interested to hear
in Montréal several people developing use cases saying : "Make Topic Maps technology in
your enterprise, but don't speak about it. Don't mention the Semantic Web. Show things
that work in the Intranet." And : "My Published Subjects would be relevant to my
community. Who would care outside it?"

That's why I think we have to split very well PSI issues and wide-spread adoption of Topic
Maps.

*Eric
> RDF and TopicMaps are trying to solve very similar problems at different
> levels of abstraction. In doing so, both of strengths and weaknesses
> depending on the particulars of the application.
>
> If I may, I'd prefer to simply accept this limitation for the sake of
> these discussions and focus on articulating 'best practices' for PSI
> that include various social, organizational and technical
> recommendations that this group agrees upon.

Agreed

*Murray
> > I'd just like a PSI for "topic documentation." And a way to
> > publish topic maps that I can point to as PSI sources. Given
> > that my first crack at that (in the XTM 1.0 Specification)
> > doesn't seem to stand up to time, I'm waiting for the alternative.

I think we're almost there

*Eric
> Suggested technical components for consideration for example might
> include capabilities such as PURLs http://www.purl.org/ for persistent
> URL identifiers and and RDDL http://www.rddl.org/ for providing a means
> for binding various syntactic means of expressing the semantics
> associated with various PSI's.

I would indeed like folks involved in PURL and RDDL (and also UDDI which is now inside
OASIS)
to bring their insight and experience and tell us if what we are trying to achieve makes
sense from their viewpoint.

*Eric
> A quick additional question... with respect the minute Recommendations
> regarding Publisher and Dublin Core.  Was examples of how this would be
> implemented discussed?

Not at that point. Just a clarification of vocabulary. What we had was a long discussion
on what "publisher" may mean, and if we wanted to give yet another definition of it. Since
we figured it's a can of worms, we've preferred to stick to DC low profile ...

*Eric
> Would the following fruit PSI example satisfy these requirements?
> http://www.w3.org/2002/05/29-psi/fruit

Seems to me at first reading. Have to look at it more closely.

> ps: thanks for the minutes, they were very helpful....

That's what they were intended to be.

Bernard