[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: Re: [tm-pubsubj-comment] Fwd : On "prohibition" of XTM and URNs
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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC