Re: [tm-pubsubj] Re: TC Website reorganization, and drafts update

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

At 03:13 PM 1/16/02 -0800, Murray Altheim wrote:
>Lars Marius Garshol wrote:
> >
> > * Mary Nishikawa
> > |
> > | For example, if Schlumberger were to implement topic maps, I do not
> > | think that we would go through the trouble and expense to create
> > | specialized xml documents to provide addressable resources for the
> > | same reasons you pointed out. There are generic PSIs that we would
> > | use though.
> >
> > My feeling is that the main cost will be in arriving at a well
> > thought-out set of subjects and text clearly documenting them, and
> > that once that's done the task of typing it in, or converting it from
> > some other format is going to be minor.
>
>If you look at the topic maps I've developed (language, country,
>region, Cycorp, ITIS zoological taxonomy, etc.) they are all
>transformations of these existing systems into XTM. The cost has
>already been assumed before I ever did anything with them, and in
>many cases there's already existing HTML documentation to provide
>subject indicators. The cost of conversion wasn't significant, but
>I'd hardly call it minor.

It is really great that Murray has already done this.

>In the case of many systems it will be
>considerable, especially if the source materials aren't already
>in addressable form.

This is so true. Documentation is not usually modularized as one document 
=one subject. We usually have one document = many subjects. The greatest 
challenge  and  expenditure will be spent on figuring out how to deal with 
the "resources" that are in such and such a system when we do not 
have  subjects in an addressable form. The commonly used subjects can be 
dealt with as Lars Marius mentioned, but on the whole there is a vast 
amount of resources in a system that are the subjects.  Some of the 
subjects are very specific, some are generalized and contain other 
subjects. There needs to be a clear strategy to deal with the information. 
This is not in the scope of this committee, but we need to keep this in 
mind when we are writing the recommendations.

> > | I would guess that the most common general use case would be PSI
> > | sets created with one or more SDD documents in html with fragment
> > | identifiers for each subject in the resource.
> >
> > I am not so sure of that. In fact, I was fairly firmly convinced that
> > PSDs would usually be published in XTM form, in order to be maximally
> > useful. Why do you think HTML is to be preferred?
>
>I think Mary is talking about the subject indicator documentation,
>which is human-readable and useful outside of the realm of XTM. The
>XTM topic maps point into the HTML files to obtain human-readable
>descriptions of the subjects. The XTM documents have only the names
>of the topics and are not really suitable as the main source of
>documentation (unless we add that PSI for "documentation" that we
>talked about at one point).

Absolutely right, but I could have been clearer. The published subject 
documentation set will contain PSIs in XTM  and will point to the html 
files that are subjects in themselves or point to subjects in the html file 
via the fragment identifiers. I was under the impression that the 
recommendation would describe XTM TM with subjects  that would point to an 
xml file for each subject with the dc metadata included. I think that this 
is unrealistic and would not be implemented in principle. Maybe this is my 
misunderstanding. If an xml file with dc metadata is not used, for example, 
then how do we describe this in the recommendation?

In one of our portals, we do have metadata for each subject (sometimes a 
huge subject containing many subjects) but it is not dc metadata nor is it 
xml, but a URL query string that brings up an html file containing the 
metadata. This metadata file has the resource attached (another URL query 
string). I would guess that in this example, I would want to use 
the  metadata file as the indicator of the subject  in the  XTM 
TM,  correct? In some cases, I might really want to go to the subjects in 
each resource, but this would be unrealistic to attempt, I think. You can 
say that, well, these are not going to be made "public" so it is not 
necessary to "publish" these subjects at all. But other portals that may be 
similar to ours may want to publish their subjects. How would they do it?

Lars, I would appreciate as simple example of what you mean by this:
"I think repeating all the metadata for each SDD is not necessary, it can 
instead be inherited from the PSD package."

Thanks.

-- Mary