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