[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: Re: [tm-pubsubj-comment] Tuesday conference
Thomas Certainly I will repeat myself here. All that stuff I've already scattered in several messages in this or other forums archives. But it will be quicker for me to repeat than to browse the archives for it :)) Steve have come lately to the conclusion that Topic Maps is not a good option for PSD, out of technical considerations. My view has been the same from the beginning of this TC process, but out of both political and conceptual arguments. It's interesting to notice that we get to the same conclusion from different ways. The political arguments I've already stressed. Locking PSIs in Topic Maps realm and technology is certainly not a good move if we want wide-spread and quick adoption. We are not sure at all of wide-spread adoption of Topic Maps technology, but I'm strongly convinced that Published Subjects have a potential scope of application much wider than Topic Maps, even if it's currently difficult to figure what is or will be the exact extension of that scope. The conceptual argument I want to repeat, because I think it is the most important one. Published Subjects ambition is to build a bridge between the "formal addressable" universe (where Topic Maps belong) and the "unformal non-addressable" universe of real world subjects (where publishers and users leave). Steve Newcomb speaks (in its chapter of the to-be published book on Topic Maps) of two cliffs separated by this chasm that everyday's use of language and conversation is bridging efficiently, but that is very difficult to bridge in our information systems. When I speak of Janus Bifrons looking inside and outside the doors, in the gentle introduction to Published Subjects, I think I am speaking about the same thing. If we use Topic Maps for definition of Published Subjects, we are putting them on the same "left-hand" cliff of the chasm, and all difficulty may disappear indeed, because it's not a bridge anymore. We have strong foundations on the left-hand side (including, but not only, topic maps). We have hard time to figure the foundations on the other side. Sure enough. But wanting to build a bridge from one side only looks to me like being the fool searching for his keys on the lightened side of the street - because it's easier to search in the light - although he knows he lost them on the dark side. Regards Bernard PS : We shall overcome ... :)) ----- Message d'origine ----- De : "Bandholtz, Thomas" <thomas.bandholtz@koeln.sema.slb.com> Ŕ : <tm-pubsubj-comment@lists.oasis-open.org> Envoyé : vendredi 3 mai 2002 09:24 Objet : [tm-pubsubj-comment] Tuesday conference PSI-junkies, the last weeks I have followed discussions with what Bernard has labelled "mixed feelings". I called in to the Tuesday conference in this state of mind, not beeing sure about my statement. So I started just listening. After one and a half hour suddenly I suspected the group (including myself) was commiting a fatal basic error. We were discussing questions of the internal structure of a PSI doc on a very abstract level. One item led to another, and I found ourselves amidst a haystack of unsolved "issues", feeling very small and far, far away from our objectives. And suddenly I remembered that most of the issues can be solved easily when we use a topic map for the PSI doc. I remember the resulting protest - OK I know we had this discussion before. But I want to raise this question again, after having had some experience with the consequences of *not* chosing topic maps. Actualy now I have four statements: 1 use Topic Maps for PSI sets 2 support both retrievable URL ("retrieval bookmarks") and URN ("unique names only") 3 integrate human and machine readability in one source 4 allow diversity of data sources media across files, databases, or whatsoever For those who are interested, here is some closer reflection (I do not want to relegate these thoughts to be some other "issues" :-) 1 use Topic Maps for PSI sets ============================= Note I do not say "XTM". The internal structure of a topic map is capable to accommodate a PSI doc. There are some issues not completely solved yet, but I see no restriction of feasability. It is our strength that we can offer a structure capable of doing so, and we should not hesitate to communicate this. As I have said during the conference, rather spontaneously, "everybody will think: they don't even believe in topic maps themselves". On the other hand, the possibly interested communities outside the TM crowd may see this as a restriction. I think the restriction will be even harder when we propose common use of PSI and not even provide a concrete structure definition. This concrete structure definition should be a topic map - what else? If someone prefers a different structure, (s)he should argue for it. In this sense, RDF is not a different structure for a PSI doc, but just a different syntax. Why not write a topic map using RDF? See the difference of saying "a topic map" from saying "XTM" ? 2 support both retrievable URL ("retrieval bookmarks") and URN ("unique names only") ============================================================================ ======== read http://www.w3.org/TR/2002/WD-xml-names11-20020403/ about namespace names: "[Definition: The attribute's value, a URI reference, is the namespace name identifying the namespace.] The namespace name, to serve its intended purpose, should have the characteristics of uniqueness and persistence. It is not a goal that it be directly usable for retrieval of a schema (if any exists). An example of a syntax that is designed with these goals in mind is that for Uniform Resource Names [RFC2141]. However, it should be noted that ordinary URLs can be managed in such a way as to achieve these same goals." No doubt: A retrievable topic map fragment in this place is best! However, something like ISBN:0201175355 is a working published subject without having any URL at all. 3 integrate human and machine readability in one source ======================================================= XML was intended to be both. Though I would consider myself to be a machine-head i see it as a question of professional ambition to make everything as human readable as possible. On the other hand, doc-heads should not be too comfortable. TM need not to be fairy tales. 4 allow diversity of data sources media across files, databases, or whatsoever. ============================================================================ == XQuery 1.0: An XML Query Language, W3C Working Draft 30 April 2002 http://www.w3.org/TR/2002/WD-xquery-20020430/ "XML is a versatile markup language, capable of labeling the information content of diverse data sources including structured and semi-structured documents, relational databases, and object repositories. A query language that uses the structure of XML intelligently can express queries across all these kinds of data, whether physically stored in XML or viewed as XML via middleware." Thomas Bandholtz CM / KM Division Manager; XML Network Moderator Competence Center Content Management SchlumbergerSema http://www.schlumbergersema.com Kaltenbornweg 3 D50679 Köln / Cologne Germany +49 221 8299 264 PS: Bernard, how was May, 1st in France?
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC