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: [tm-pubsubj] Subject Definition Resource and Published SubjectsDocumentation


Mary

> 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 think it's in the scope of our TC reflection to try and figure out as many use cases as
we can, and to sort out what are the best practices. Clearly, a favorable use case is to
have a documentation already organised in "smallest reusable documentation parts" - parts
of a documentation that make sense standalone, but can't be split anymore without loosing
their meaning. Which generally mean that they deal each with one specific subject. Say
e.g. a technical description of a given item in a catalogue.
BTW in Mondeca, we are working on such a general methodology with customers with huge
documentations (namely legal, financial, chemical). From a classical documentation
organized in sections, chapters, paragraphs, or equivalent structures in a web
publication, we try to extract the smallest reusable parts (in XML files, addressable
subjects of topics) on one hand, and OTOH the structure of relations in terms of topic
associations. Smallest reusable parts are ready-made for being subject definition
documents, (and for being reorganized in any customized way, which is generally where the
customer is seeing first ROI).

It's in the scope of our TC to try and set guidelines that clearly say to documentation
managers and publishers: this kind of structure you have now is really fit for providing
published subjects documentation, and that one clearly is not, but if you transform it in
such and such a way, it could be.

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

It could be done that way, but I won't recommend it as a best practice, because although
it's clear what is the Subject Indicator Reference in this case, it's not clear to me what
is the Subject Definition Resource. Seems to be split into two parts, one containing the
metadata, and the other I don't figure what exactly. It seems to me you use "subject"
there in a very loose sense. Do you mean the "resource attached" is the (addressable)
subject there?

> In some cases, I might really want to go to the subjects in
> each resource, but this would be unrealistic to attempt, I think.

What do you mean by "go to the subjects" exactly?

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

The notion of "published" does not necessarily mean "public" in the sense "published for
everybody on the Web". You can use published subjects for a limited publication space,
e.g. enterprise intranet or community portal. I do believe indeed that it is the most
probable use case, and one we should have in mind when setting our recommendations. Use of
published subjects, and of topic maps at large, need that human actors in all the
information space (publishers, authors, users) share more or less the same ontology, and
have interest in using it. Published Subjects for Oilfield Services specific technologies
won't be of any interest outside the scope of oil industry, I think, and it would not make
much sense to have them "public" on the Web.

Bernard




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


Powered by eList eXpress LLC