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

[Lars Marius Garshol <larsga@garshol.priv.no>]

* Mary Nishikawa
| 
| 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'm not sure exactly what you are thinking here, but it seems to me
that to distinguish between published subjects and ordinary subjects
is useful here. Not every subject needs to be published, only the key
ones that are intended for use in a large audience, and/or necessary
for correct merging. 

It sounds to me like you are talking about a large information space
where only a few subjects actually need to be published, while the
rest can be ordinary subjects. If that is the case publishing the
published subject is not going to be all that much work, no matter
what syntactical form is chosen.
 
| 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.

Now we're on the same page. I consider this to be absolutely OK,
although I would prefer the definitions to be in the XTM document
where possible. That does not preclude their publication in HTML form,
so long as the XTM version remains the point of common reference.

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

I don't like this solution either, especially as the DC metadata could
be included right in the XTM topic map. I think many people will want
to provide some DC metadata, but probably not all. IMHO people should
be encouraged to do so, but not required.

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

What do you mean?
 
| 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? 

Not necessarily. You could do it, but you could also choose to use
some other URI. The fact that some documentation for the subject can
be found at that URI does not in any way compel TM authors to use that
particular URI as the subject indicator reference. You might establish
a different set of URIs and recommend their use instead. Duplication
is in this case no problem.

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

I'm not sure I understand this question. What is the problem you
perceive here, and would like have recommendations on solving?
 
| 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."

Well, the first draft suggested that published subjects should provide
information like publisher, creator, source, history, etc, but in most
cases this information would be identical for all the published
subjects in a PSD package, and so I thought it would be impractical to
repeat it for every single published subject when it could be asserted
once in the PSD instead.

When the GeoLang TC publishes the ISO 639 language PSI set it should
have to repeat for every single language that the source is ISO 639.
Instead, this could be asserted once, on the PSD package, by saying
that the source of this PSD is ISO 639.

The question is, of course, whether we should allow this to be
asserted for each published subject individually or not.

--Lars M.