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


Steve, Lars Marius

Thanks for putting that on the table. Two main comments:

1. PSIs strike back ... funny indeed. Remember the argument we had in Orlando for giving
up PSI was the ambiguity of the term.
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 ...

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.

Otherwise:

> subject indicator
> -----------------
>
>   "A subject indicator is a resource that is intended by the topic map
>   author to provide an unambiguous indication of the identity of a
>   subject. Any resource can become a subject indicator by being
>   referred to as such from within some topic map, whether or not it
>   was intended by its publisher to be a subject indicator."

I like it.

> subject indicator reference
> ---------------------------
>
> Not defined in the terminology part of XTM. Used only for the
> <subjectIndicatorRef> element. Suggest we don't need to define it here.

I won't fight on that. Maybe Murray will :))

> publisher
> ---------
>
> What are we going to use this term for? Why do we need to define it?

We won't *define* it. My point is that we use it all along the document, and it was just
to insist on the fact that we'll use that term in conformance with its Dublin Core
definition. No more. That needs not be in the glossary, in fact, but in the introductory
prose.

> published subject
> -----------------
>
> This term is not defined in the terminology section of XTM 1.0.
> The definition quoted in psdoc is taken from the text in 2.3.1.
>
> We suggest a simpler definition than the one in psdoc:
>
>   "A subject for which there exists at least one published subject indicator."

Agreed

> subject definition resource
> ---------------------------
>
> Like Mary, we don't see the need for this when we already have "published
> subject indicator".

OK - with the above caveat

> published subjects documentation
> --------------------------------
>
> (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"

> (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.

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

> published subject indicator
> ---------------------------
>
> psdoc, following the provisional terminology established in Orlando,
> uses "subject definition resource". We think, however, that published
> subject indicator, abbreviated PSI, is cast in stone. Some people
> might not like it, but it's too much a part of topic maps now to be
> thrown out. The definition in XTM is, we think, good enough:
>
>   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 ...

> published subject identifier:
> -----------------------------
>
> After due consideration we really think we need a term for the URI of
> a published subject indicator, e.g. for the string
> "http://www.topicmaps.org/xtm/1.0/core.xtm#sort".
>
> >From the machine processing standpoint, these strings are as important
> (actually, more important) than the human readable resources that
> indicate the identity of a subject and they need to be up there among
> the other defined and named concepts.

Agreed. But for machines, it makes no difference if they are published or not ...

> What distinguishes the PS identifier from being just the URI of a
> subject indicator is that it is the URI chosen to be the identifier of
> the subject, that is, it is the canonical published subject indicator
> URI.

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.)

> We propose the following definition:
>
>   "The canonical URI of a published subject indicator, chosen as the
>   URI to be used within topic maps to identify the published subject."

ditto ... chosen *by the publisher*

Bernard




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


Powered by eList eXpress LLC