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] 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