[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: Re: [tm-pubsubj] Subject Definition Resource and Published SubjectsDocument
Bernard: 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. Mary: I agree, "smallest reusable documentation parts" is best. I think that our committee will provide recommendations to publishers to go this route in the future. What happens is, the current state of browsers cannot handle our smallest, reusable document modules in xml (actually containing indexing terms in specific tags), and present them as a complete document (using xInclude, xlink. etc.), so we are assembling the xml documents (HyTime linked) which becomes an html file. This file them becomes our "publication unit" stored in yet another DB. Bernard: 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). Mary: I look forward to discussing this with you in Seattle. It has been a little frustrating for me seeing the future, but not being able to move things forward quickly enough. It's one of the reasons why I an here. It is a very exciting and will be quite rewarding I think when this can get implemented ;-) Bernard: 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. Mary: Oh, yes. Exactly. Mary> 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? Bernard: 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? Mary: This is the problem. What we have defined as the definitive resource for a product is in fact a huge manual in html or pdf. These manuals are most often zipped pdf or html attachments to the metadata file that contains a short summary of what the resource is, date of publication, publisher, owner, shared by, etc. and is also classified into various categories, both broad and narrow. This does not seem to be a good practice, not in terms of implementing TM, anyway. We do not publish the individual modular xml files as equivalent modular html files, even though the source files were modular to begin with. Maybe Murray would recommend publishing them as modular xhtml, which is something to consider. It would be nice if both the modular and assembled files were published, but this is not what is done yet. This may be the best practice. Mary> In some cases, I might really want to go to the subjects in > each resource, but this would be unrealistic to attempt, I think. Bernard: What do you mean by "go to the subjects" exactly? Mary: If I had a fragment identifier for each of the subjects in the manual (like my good old hand-crafted html files did) then I could have used them as SIs in my TM. There is nothing now that I can "grab onto" so to speak. Mary > 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? Bernard: 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. Mary: I see at least three use cases: The first, strictly following recommendations and the last, loosely following it: Public use PSIs, extranet PSIs (shared by partners multiple companies) and intranet PSIs (internal confidential). For the internal PSIs, by loose, I mean that we might not have metadata files. It may just be an internal taxonomist in charge of maintaining the PSI set. Since it is internal, it is easier to control. Nobody else will depend on it. I don't know if we would need to actually "declare" the SIs as stable and definitive as long as we agree internally that they are. Unfortunately, corporate life is ever changing, as Murray pointed out, so these SIs in my TM may not be Published Subject Resources after all, but nobody else depends on them, so I don't need to worry? To be continued... Cheers, Mary
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC