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 attempt at terminology


At 20:54 28/01/02 +0100, Bernard Vatant wrote:
>1. PSIs strike back ... funny indeed. Remember the argument we had in 
>Orlando for giving
>up PSI was the ambiguity of the term.

I think I was the one who proposed not using the term "PSI" in Orlando. But 
I didn't intend to "give it up" forever. My goal was to help us clear the 
cobwebs out of our brains and understand what the pieces of the puzzle were 
before worrying too much about naming them. (That's why I went in for long, 
explanatory names that I didn't expect to be adopted as final.)

>Now you seem to say we have to bring it back *because of* this very 
>ambiguity. Although I
>like the whole aesthetics of the idea, I wonder if it is sustainable to 
>set a vocabulary
>whose whole purpose is clarification and disambiguation of subjects, 
>around a deliberately
>ambiguous acronym - even "cast in stone" - that has two different 
>expansions and meanings,
>so close to each other that certainly people will have hard time to 
>discern them. Think
>about the time we took ourselves to get there ...

Yes, but we got there and now we understand the picture fairly well -- and 
hopefully are able to explain it! Now the time has come to choose the best 
possible names, within the limits of what our historical baggage allows. 
Your discussion of the "definition/identifier" duality  (corresponding to 
"machine/human") helped a lot. If we make sure that this comes across in 
our deliverables, then the duality of the PSI acronym makes sense, and may 
even aid understanding.

>2. If we want to have a "closed" terminology, why give up "subject 
>identifier"? I don't
>follow Mary and you on that track.
>If a topic map author uses a subject indicator which is not declared as 
>published, is not
>the URI of this subject indicator a "de facto" subject identifier, by the 
>simple process
>of being used - the same way the resource used is a "de facto" subject 
>indicator?
>Suppose I use www.w3.org as an identifier URI for the topic "W3C", even if 
>W3C does not
>care about it.  Several maps could use that same URI, and it will be used 
>by TM engines
>the same way as an identifier when processing those TM, be it published or 
>not.

I don't have too strong a position on this. I could go along with subject 
identifier even just for the sake of a "closed" terminology, but I think 
you are probably also right that people will have a use for this term.

> > (1) The use of plural form ("subjects") is not good from a language
> > point of view. This can quite happily be called "published subject
> > documentation" even if it is about documentation that may cover
> > multiple subjects, so the name of the term should be changed.
>
>Hmmm ... "one step forward, one step backward"

Sorry for not speaking up earlier when you raised the suggestion. I was 
buried under a ton of work and didn't even see it until after you'd changed 
the document.

> > (2) "Documentation" is non-discrete: you cannot have "a documentation"
> > (nor "several documentations"), so the definition also needs changing.
>
>Ah ... I was not really aware of that. FYI in French, we can use 
>"documentation" for a set
>of documents, as well as the office where the documents are held, the 
>department managing
>them ... and the process of documenting.

Those usages are OK in English as well, even the use of "documentation" for 
a set of documents. But you still can't talk about "a documentation" or 
"many documentations". Can you really do that in French? ("Nous avons deux 
documentations"???)

> > To solve these problems we think the term "published subject
> > documentation set" is needed, and it can be defined as follows:
> >
> >   "The complete set of documentation about a set of published
> >   subjects, as published by the publisher."
>
>Not very elegant, but explicit.

We really wracked our brains to find something more elegant, but we failed. 
If anyone has an alternative proposal, let's hear it. The key point is that 
we think we will seldom need to talk about a set of documents that 
constitute the documentation for a single published subject, but we *will* 
often need to talk about the set of documents that constitute the 
documentation for a whole set of published subjects, usually within a 
certain domain.

> > published subject indicator
> > ---------------------------
> >
> > ...
> >
> >   A subject indicator that is published and maintained at an
> >   advertised address for the purpose of facilitating topic map
> >   interchange and mergeability."
>
><sigh> All that road for coming back home ...

Think of it like this: We have gathered much experience along that road and 
now we are all older and wiser :-)

>To be explicit, we should say "chosen by the publisher". (Because an 
>author, or a gang of
>authors, can also choose an URI as subject identifier, see above.)
>
>...
>
>ditto ... chosen *by the publisher*

I'm happy with both of those additions.

Do you have a chance of working all of this into a revised version of the 
document before the concall? I think it would make our discussions more 
effective.

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



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Powered by eList eXpress LLC