[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: RE: [tm-pubsubj] New Gentle Introduction
Steve Eventually, blood got out of the stone! Good job, actually ... in spite of all below remarks: - Section 1, second para: "It is also a goal is that such interoperability ..." Typo: one "is" too much - Section 2.1 - first para " ... a class of such individuals, like "famous scientists", "fruit", or "OASIS recommendations" ..." The question of singular or plural form for class expression has been discussed but not settled during last meeting. See my opinion on that in message sent two weeks ago, supporting singular form. Seems I was quite alone on that position, and that now nobody cared even to discuss it any more :( In any case, it should be at least consistent: either: "famous scientists", "fruits", "OASIS recommendations" or "famous scientist", "fruit", "OASIS recommendation" - Section 2.1 - second para "... formal representations using electronic symbols as proxies ..." Not sure "using electonic symbols as proxies" clarifies anything. 1. "representation", "symbol", "proxy" seem quite redundant. 2. What is an "electronic symbol" ?? 3. When a topic map is represented as a document (XTM syntax, text or graphical display ...) what is "electronic" in the representation? Information technologies are not bound forever to electronics. There have been papyrus, paper ... and what is next? Will we review the specification when bio-computers hit the market? :)) - Section 2.1 - last sentence "well defined" should read certainly "well identified" since all we are about is subject identification, not subject definition (whatever the latter means, it is in the content of the subject indicator) - Section 2.2 "When aggregating information through merging topic maps ..." Merging topic maps, (and even information aggregation), is only one among so many scenarios needing subject identification. I'm not sure if we should mention it at all here, and if we do, we should mention other scenarios, like matching ontologies or XML vocabularies. - Section 2.4.1 - Note I'm not sure that "the subject indicator can be also considered as a subject" is "important to note". It is more confusing than anything else. The "subject indicator as subject" is difficult to grasp, has no real application scenario, and become very confusing: what would be the subject identifier of the "subject indicator as subject"? It's not a good idea to attract attention on that rather academic issue. This note is somehow redundant with the one in 2.4.2, which is much more explicit. - Section 2.4.2 "If two topics have the same subject indicator, then by definition they represent the same subject and should be merged" Same remark than in 2.2. Merging is only one scenario, specific to topic maps processing. It's up to applications to decide what to do with the fact that two subjects are equal. SAM-conformant applications will have to merge, but others can do anything else they consider relevant. - Section 2.6 Good marketing, which was really lacking. Rather than "future" (the specification is here to stay) I would suggest something like "Scenarios for PSIs development". More to come, certainly. Bernard _____________________________________ Bernard Vatant Senior Consultant - Knowledge Engineering www.mondeca.com _____________________________________ | -----Original Message----- | From: Steve Pepper [mailto:pepper@ontopia.net] | Sent: vendredi 21 février 2003 10:21 | To: tm-pubsubj@lists.oasis-open.org | | Many thanks for your feedback, Peter. I've updated the document at | http://www.ontopia.net/tmp/pubsubj-gentle-intro.htm. | | Those of you who haven't yet sent comments should refer to the | latest version. | | At 22:35 20.02.2003 +0000, Peter Flynn wrote: | >This is very good. | | Thank you. But still not good enough, I fear. | | >1. The concept of merging topic maps is introduced via an oblique | > reference (2.2, "When aggregating information through merging | > topic maps"). Do we need to explain why one might want to merge | > topic maps at all? | | This goes almost to the heart of my concerns about the text as it | currently stands. I fear we simply *assume too much*. We don't | answer the "why should I care?" question. | | You're right that the reference to merging appears out of the blue. | I think this will sort itself out once we know what needs to be said | in order to cater for those that don't already share our basic | assumptions. At the moment I don't know what it is that needs to be | said. Suggestions welcome. Why not try the text out on some | unsuspecting colleagues who represent our target audience? | | >2. In 2.4.1, para after the Note, "Provided with a subject indicator, | > human users should be able to know what subject the topic | > represents." There isn't an antecedent referent for "the topic" | > here, and the reader may have forgotten the basic premise in 2.2 | > ("Every topic must represent exactly one subject and every subject | > must be represented by exactly one topic.") because that's quite | > a long way back. | | Good point. I don't think it's actually necessary to mention the | topic at this point. Changed to "able to know what subject is being | referred to". (Excuse the DP.) | | >3. In the headings for 2.4.1 and 2.4.2 can we highlight "Indicator" | > and "Identifier" (bold italics, underline, whatever) to emphasize | > the distinction between the two sections? | | I think we could, yes. | | >4. In 2.5.1, can we emphasize the caveats from "whether or not..." | > to the end of the second sentence? | | Done. | | >5. 2.5.2 is excellent, something we can give even to the least aware | > publisher. | | If that's true, we must be getting close :) | | >6. In 2.5.3, do we assume the reader understands that this is all | > subject to standard business uncertainty (ie Fruit.Org, Inc, is | > taken over by International Juice Conglobulation, Pty, who don't | > give a pith about Published Subjects and who trash the server? | | I'm not sure whether we want to harp on that too much. We've mentioned | stability and trustability (?) and we chose a .org rather than a .com | deliberately, so I think we leave the reader to draw conclusions | like this herself. | | Thanks again, Peter. You didn't mention 2.6, which is the bit I'm | least happy with. | | Steve | | -- | Steve Pepper, Chief Executive Officer <pepper@ontopia.net> | Convenor, ISO/IEC JTC1/SC34/WG3 Editor, XTM (XML Topic Maps) | Ontopia AS, Waldemar Thranes gt. 98, N-0175 Oslo, Norway. | http://www.ontopia.net/ phone: +47-23233080 GSM: +47-90827246 | | | ---------------------------------------------------------------- | 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