Re: [tm-pubsubj] Re: [tm-pubsubj-comment] Comments on Use Case

[Mary Nishikawa <nisikawa@fuchinobe.skk.slb.com>]

Suellen, Bernard,

Thanks for your comments and for filling in the details. I will work on the 
Use Case a little more.

I would really like to have in mind all players that could benefit from this,
and I'm not only talking about the community involved in topic maps and 
related
technologies but also the public at large.

I keep going back to the ISO 13250 Topic Map Specification.
I think I need some clarification about the definition of Published Subjects
and how it relates to but is different from a Public Subject Descriptor.

Subject Descriptor and Public Subject Descriptor as defined in ISO 13250:

"A subject descriptor is a reference to a positive, unambiguous, indication 
of the identity of a subject.
For example, it could be a reference to some descriptive text, a Dewey 
Decimal Code or a Universal Decimal Classification. A public subject 
descriptor is a subject descriptor which is designed to be used as a common 
referent of the identity attribute in many topic maps."

"Any two topics that have the same URI as the value of their identity 
attribute  are considered to be equivalent to a single topic that is the 
union of the  contents of the two topics, and of any associations that 
reference them."

Are there elements of the Public Subject Descriptor that hold true for a 
Published Subject? How are they different? A Published Subject would follow 
along the lines of the Public Subject Descriptor but would also be a stable 
online reference?   I think we need to compare and contrast these terms, 
including PSI, in a definition for a Published Subject to clear up and 
misunderstanding (myself included).

It might not have been clear enough in the Use Case I submitted, but I 
wanted to  propose the use of some standard numerical code in a URI, based 
on what I read from the ISO standard.

I was envisioning  TM authors following ISO 13250 using something like this 
this if they wanted to merge their topics:

<Topic id="topicidname" identity = 
"http://www.purl.org/pubsubjSourceName/UDC/UDCcodexxxx/descriptiveTitle/">

In the above instance, it does not resolve to anything, because is just a 
descriptor?

How would this work with Published Subjects, if at all?

How about this?
A source would register the location of their Public Subject with purl. 
They are classifying their subject based on some  system, could also be 
ISBN for instance, and then state the code, then some title of the subject, 
etc.

The perl uri would redirect to the  source's own domain. This seems like 
something the source would agree to.

If a topic map author were following the XTM Specification, the above 
example would look like this?

<subject-identity>
<subjectIndicatorRef 
xlink:href="http://www.purl.org/pubsubjSourceName/UDC/UDCcodexxxx/descriptiveTitle.xml/>
</subject-identity>

or could it possible look like this?
<subjectIdentity>
<subjectIndicatorRef 
xlink:href="http://www.purl.org/pubsubjSourceName/UDC/UDCcodexxxx/scopename.xml#subject/>
</subjectIdentity>

These are just some ideas I would like discussed before the meeting. Thanks.

Best regards,
Mary





At 04:34 PM 11/7/01 +0100, Bernard Vatant wrote:
>(Sorry for double posting: Suellen started the thread on 
>tm-pubsubj-comment, but IMO
>it is more technical TC work, and should be followed on tm-pubsubj)
>
>We need maybe some clarifications. I'll try to make a clear distinction 
>between
>different viewpoints, herafter called (subject) "Source", "Publisher", 
>"Author" and
>"User", because it seems to me that both Mary's proposition and Suellen 
>answer
>somehow mix those different viewpoints.
>
>"Source" is the primary reference creator/publisher of the subject(s). It 
>should be an
>(authoritative) entity, managing, editing, publishing a legacy of taxonomy,
>classification, thesaurus, vocabulary ...*under any form*.
>ex: Library of Congress is Source for LCC categories, DCMI is Source for 
>Dublin Core
>elements ... The primary reference is generally not (so far) a Published 
>Subject (in the
>sense we are trying to define in this TC), e.g. it might not be a stable 
>on-line resource.
>
>"Publisher" may be
>
>-- either a "Source" entity wanting to make its resources available as a 
>set of
>standardized Published Subjects. For example Library of Congress could 
>want to
>make its categories available as Published Subjects (let's dream for a 
>while). In that
>case, Publisher and Source are the same entity, and all is the best 
>concerning
>validation, IPR, management. That is the use case we should recommend and 
>aim to.
>We should provide existing entities with recommendations and methodology 
>to make
>their legacy available as standardized Published Subjects, and not make 
>that work on
>their behalf, which would be "foolhardy" and silly, as Suellen points out 
>accurately.
>
>-- either an entity already using part of whole of one of the above 
>classifications, and
>wanting to make them available as a set of Published Subjects, because the 
>Source is
>not able or willing to do so. For example Vanderblit University Library 
>would like to
>make LCC they use in their documentation management available as Published
>Subjects, because Library of Congress has not made it. In that case, the 
>Publisher
>acts as a proxy for the Source, and of course it creates specific issues 
>of validation,
>update, IPR, and a duplication of efforts. This could be used as a 
>transition process, to
>kick off the bootstrap of Published Subjects wider adoption, but should 
>not be a
>generally recommended process.
>
>"Author" is a Topic Map creator and editor, that will use authoritative 
>and trustable
>Published Subjects whenever available for its needs, through 
><subjectIndicatorRef>.
>The relevancy and accuracy of the reference is completely under the 
>responsibility of
>the Author, and yes, it is a knowledge expert work, and no, you should not 
>let children
>play with that knife. If you are not clear and use a reference to an 
>explicit and crystal-
>clear Published Subject *cancer* for a Topic gathering documents about 
>*pneumonia*,
>well, you are a non-knowledgeable Author ... and too bad for the users of 
>your work ...
>but there is something the Publisher can do about it: refuse to register 
>this Topic Map
>in its Published Subjects declaration like a referenced <user>
>
>Now if the Author is working on behalf of a Publisher, itself a Source ... 
>that's as best
>as one can get: e.g. a Topic Map published and validated under direct 
>Libray of
>Congress authority, using LC Published Subjects based on LCC ... will 
>certainly be
>more trustable than one of some obscure Author referring to some obscure 
>Publisher
>using LCC in some non-controlled way ...
>
>And of course, any Author can become a "local Publisher" by setting a set 
>of specific
>Published Subjects for the need of a small community. And of course the 
>use of
>Published Subjects and the use at all of Subject Indicators is optional ...
>
>Now for the metaphysical question "Is the Published Subject I use, as an 
>Author, the
>best one?" there is no technical answer. But Publisher could help by being 
>itself, and
>making potential Authors, aware of Published Subjects equivalent to its 
>own, and
>making them visible and available. That is the role of the <equivalent> 
>element in the
>proposed DTD. To quote Suellen's example, if I use DDC and am not aware of 
>LCC,
>OTOH maybe DDC Published Subjects authority is aware of LCC, and refers to 
>them.
>But that is up to the DDC Publisher to include in its Published Subjects 
>references to
><equivalent> LCC, and the other way round.
>
>So, I suppose we should think about Dublin Core use in that spirit:
>
>1. We have several Sources, will they be Publishers?
>2. If not, who's gonna do it?
>3. How will we provide Publishers the more simple way to link consistently 
>with each
>other?
>
>Bernard
>
>
>
>
>
>----------------------------------------------------------------
>To subscribe or unsubscribe from this elist use the subscription
>manager: <http://lists.oasis-open.org/ob/adm.pl>