[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