[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: A bit of context RE: [tm-pubsubj] RE: [VM,ALL] Revised scope statement
The previous message is forwarded from a thread in W3C SWBPD WG about the definition of a "Vocabulary Management" Task Force, of which scope and objectives are as close as can be to PubSubj's. You can follow the thread (and jump in if needed) at http://lists.w3.org/Archives/Public/public-swbp-wg/2004Jun/0066.html where the TF is defined. Bernard Vatant Senior Consultant Knowledge Engineering Mondeca - www.mondeca.com bernard.vatant@mondeca.com > -----Message d'origine----- > De : Bernard Vatant [mailto:bernard.vatant@mondeca.com] > Envoye : jeudi 17 juin 2004 11:30 > A : SW Best Practices > Cc : tm-pubsubj > Objet : [tm-pubsubj] RE: [VM,ALL] Revised scope statement > > > > Tom > > Thanks for your clarifications > > > According to http://www.w3.org/2004/03/thes-tf/mission, the > > THES/PORT Task Force wants to focus on guidelines and tools > > for representing structured vocabularies using RDF/OWL. > > Yes > > > To my way of thinking, the Vocabulary Management TF would, > > in contrast, focus on the identification of terms (and of > > versions of terms and sets of terms) and on policies and > > practices related to the identification of terms. > > The real issue here is to know if it makes sense to identify terms (or anything else) > independently of any application context. For example, in a Thesaurus, the application > context of a term (i.e. its contextual definition) is expressed by its BT, NT, RT, UF, > USE, Scope Note ... If you strip a term off all this contextual information, > what's left? > a name? a URI? A bare identifier without any identification context is as useful as a > credit card number outside any banking system. > IOW, relationships between identification and contextual definition are tricky to > entangle, and setting generic term identification valid for *any* context seems very > difficult (read : barely possible). > > > I sense that we might plausibly agree on some basic principles > > regarding identification and on the need to articulate one's > > policies, but that there is still "an evolving diversity" of > > approaches towards documenting, representing, and publishing > > a vocabulary. > > > > But that's okay -- at that point, the VM TF could simply point > > off to other documents and practices such as the the THES/PORT > > TF note and the OASIS Published Subjects work you cite below. > > If that means : There is a generic question of term identification, generic principles > that can be set in the SW context (see below), but specific ways to apply those > principles > always depend on context (e.g. Thesaurus, Ontologies, Topic Maps, Taxonomies ...) then I > agree. > BTW such an approach could help to get out of the endless debate on URI meaning, by > stressing the (IMO obvious) fact that whatever an identifier identifies > necessarily always > assumes an application context, and that the Web (semantic or otherwise) can barely be > considered a univocal application context ... > > > > 2. I share the concern expressed by Alan about "terminological" vs > > "conceptual" approaches > > > of Vocabulary, and the need for clarification about it in the SW community. > > SKOS input is > > > certainly to be brought to the table, as well as current debates about use of > > dc:subject > > > in various places. > > > > My instinct would be to cite such debates where appropriate > > but to put alot of these issues out of scope for the VM TF > > note itself and focus on lower-hanging fruit. For example, > > can we agree that terms should be both identified with URIs > > and labelled with human language? > > Hopefully this is a reasonable consensus basis. > > > > 3. It strikes me how the scope and objectives are quite similar to those we > set three > > > years ago when founding the OASIS Published Subjects Technical Committee: > > > http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=tm-pubsubj > > > Note that this TC work has been in sort of standby for a year or so, out of > > both lack of > > > task force, and lack of consensus about how to tackle further deep the > details of very > > > difficult issues left on the table: > > > http://www.oasis-open.org/committees/tm-pubsubj/docs/recommendations/issues.htm > > > even if a very generic recommendation was eventually released in 2003: > > > http://www.oasis-open.org/committees/download.php/3050/pubsubj-pt1-1.02-cs.pdf > > > > > > I hope this work "as is" could be food for thought for this TF. > > > > The generic recommendation is nicely written. > > Congratulations passed to the TC list - and particularly to Steve Pepper. > > > I read it as > > saying, in essence: "Subject headings intended for use with > > Topic Maps should be identified with URIs, labelled with human > > language, accompanied with a statement of intended use, and > > described with metadata." > > If this paraphrase does justice > > to the recommendation, then it would seem to fit perfectly > > with what I think the VM TF note should say. > > Agreed, with some minor corrections to your paraphrase. > 1. "Subject headings" is somehow a restriction of scope of PubSubj recommendation, which > is about "subjects" in the widest possible sense, not only those defined in > vocabularies. > But this restriction is valid in VM TF scope. > > 2. Topic Maps is the original application context for PSI. But as the > introduction of the > quoted recommendation hopefully makes clear, it's not the only one. > > 3. The "human language label" requirement is also a restriction of the PubSubj > recommendation, which simply states that a subject indicator should be "human > interpretable". Think about the specific shade of blue defined by the RGB code #021A81. > This is barely a "human language label", but the color itself is pretty well defined by > the "human readable" subject indicator http://mediagods.com/tools/rgb2hex.html?464,294 > > > The open issues, on the other hand, seem to shade off into > > community-specific philosophy with regard to the nature of the > > terms identified and of the relationships among terms. They > > reflect that "evolving diversity" of choices about which "good > > practice" may for valid historical reasons be still unclear -- > > things like "# versus /", the descriptive attributes of terms, > > and details on publishing related documentation and metadata. > > > > Again, for such issues of "evolving diversity", I think the > > VM TF note should simply summarize and point to ongoing work. > > The VM TF membership would be hopefully diverse enough that we > > could among ourselves come up with a reasonably representative > > set of relevant citations. > > Agreed > > Bernard > > Bernard Vatant > Senior Consultant > Knowledge Engineering > Mondeca - www.mondeca.com > bernard.vatant@mondeca.com > > > > -----Message d'origine----- > > De : public-swbp-wg-request@w3.org > > [mailto:public-swbp-wg-request@w3.org]De la part de Thomas Baker > > Envoye : jeudi 17 juin 2004 05:30 > > A : Bernard Vatant > > Cc : Thomas Baker; SW Best Practices > > Objet : Re: [VM,ALL] Revised scope statement > > > > > > > > On Wed, Jun 16, 2004 at 06:05:18PM +0200, Bernard Vatant wrote: > > > I have a few general comments about this TF proposal. > > > > > > 1. Seems to me there is a great deal of overlap with PORT, alias THES, TF. > In fact, I > > > understand VM work to be in many respects an extension or generalization of > THES work, > > > since a Thesaurus is a specific organization of a Vocabulary for a specific > > application > > > (unless I miss something). How will the two TF define their specific scope? > > > > According to http://www.w3.org/2004/03/thes-tf/mission, the > > THES/PORT Task Force wants to focus on guidelines and tools > > for representing structured vocabularies using RDF/OWL. > > > > To my way of thinking, the Vocabulary Management TF would, > > in contrast, focus on the identification of terms (and of > > versions of terms and sets of terms) and on policies and > > practices related to the identification of terms. > > > > I sense that we might plausibly agree on some basic principles > > regarding identification and on the need to articulate one's > > policies, but that there is still "an evolving diversity" of > > approaches towards documenting, representing, and publishing > > a vocabulary. > > > > But that's okay -- at that point, the VM TF could simply point > > off to other documents and practices such as the the THES/PORT > > TF note and the OASIS Published Subjects work you cite below. > > > > > 2. I share the concern expressed by Alan about "terminological" vs > > "conceptual" approaches > > > of Vocabulary, and the need for clarification about it in the SW community. > > SKOS input is > > > certainly to be brought to the table, as well as current debates about use of > > dc:subject > > > in various places. > > > > My instinct would be to cite such debates where appropriate > > but to put alot of these issues out of scope for the VM TF > > note itself and focus on lower-hanging fruit. For example, > > can we agree that terms should be both identified with URIs > > and labelled with human language? > > > > > 3. It strikes me how the scope and objectives are quite similar to those we > set three > > > years ago when founding the OASIS Published Subjects Technical Committee: > > > http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=tm-pubsubj > > > Note that this TC work has been in sort of standby for a year or so, out of > > both lack of > > > task force, and lack of consensus about how to tackle further deep the > details of very > > > difficult issues left on the table: > > > http://www.oasis-open.org/committees/tm-pubsubj/docs/recommendations/issues.htm > > > even if a very generic recommendation was eventually released in 2003: > > > http://www.oasis-open.org/committees/download.php/3050/pubsubj-pt1-1.02-cs.pdf > > > > > > I hope this work "as is" could be food for thought for this TF. > > > > The generic recommendation is nicely written. I read it as > > saying, in essence: "Subject headings intended for use with > > Topic Maps should be identified with URIs, labelled with human > > language, accompanied with a statement of intended use, and > > described with metadata." If this paraphrase does justice > > to the recommendation, then it would seem to fit perfectly > > with what I think the VM TF note should say. > > > > The open issues, on the other hand, seem to shade off into > > community-specific philosophy with regard to the nature of the > > terms identified and of the relationships among terms. They > > reflect that "evolving diversity" of choices about which "good > > practice" may for valid historical reasons be still unclear -- > > things like "# versus /", the descriptive attributes of terms, > > and details on publishing related documentation and metadata. > > > > Again, for such issues of "evolving diversity", I think the > > VM TF note should simply summarize and point to ongoing work. > > The VM TF membership would be hopefully diverse enough that we > > could among ourselves come up with a reasonably representative > > set of relevant citations. > > > > > Looking into the details, I found at least a dozen of very difficult and open > > issues on > > > the table. The objective of capturing the state of the art for all of them > in a single > > > technical note seems highly challenging, to say the least. So I was about to > > say "count me > > > in" for this TF ... but OTOH I'm a bit scared to get lost again in a known maze :( > > > > It was precisely this fear that motivated me to ask for a > > conference call. I agree we could easily get bogged down by > > wading too far into detail. The diversity of trees, however, > > should perhaps not prevent us from stepping back and describing > > the forest. > > > > Tom > > > > -- > > Dr. Thomas Baker Thomas.Baker@izb.fraunhofer.de > > Institutszentrum Schloss Birlinghoven mobile +49-160-9664-2129 > > Fraunhofer-Gesellschaft work +49-30-8109-9027 > > 53754 Sankt Augustin, Germany fax +49-2241-144-2352 > > Personal email: thbaker79@alumni.amherst.edu > > > > > > To unsubscribe from this mailing list (and be removed from the roster of the > OASIS TC), go to http://www.oasis-open.org/apps/org/workgroup/tm-pubsubj/members/leave_workgroup.php.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]