Re: Comments on SKOS Extension for Sub. Indexing

Hi Jakob,

Thanks for your analysis/comment on my work.

Nabonita Guha wrote:
> 
>>> I've proposed some additional classes and properties as an extension
>>> of SKOS for subject indexing language. I welcome comments/suggestions
>>> from all group members and SKOS developers on this extended schema.
>>> 
>>> The extension is broadly designed for semantic document annotation
>>> systems. I've tried to supplement some classes and properties for
>>> subject indexing  in the original skos schema. I've expressed a
>>> concept coordination model in the extension because subject indexing
>>> languages emphasize on two main processes: analysis of subject
>>> components (facetization) and coordination (ordering) of concepts.
>>> The extension expresses the model of Postulate based Permuted Subject
>>> Indexing (POPSI) language.
> 


Jakob Voss-4 wrote:
> 
> 
> Well, frankly speaking I disagree with your proposal. Ranganathan's
> facets may seem fundamental but they are still artificial. They are just
> *one* possible way of facet analysis. SKOS should not make them
> permanent but allow *any* set of facets.
> 

Definitely, there should not be close set of facets. But the facets defined
by Dr. Ranganathan are the fundamental which can be further extended to get
the desired level of specificity in facet analysis and coordination.
Ranganathan's set of facets may seem artificial but are logical. The same
set of facets has been redefined by Dr. Bhattacharya in POPSI.



> I don't know who at this mailing list is familiar to subject indexing
> and the terms as you define them. As far as I understand you speak about
> what I know as "syntactic indexing" (you also call it "deep structure
> indexing). For those who don't understand what I am talking about please
> have a look at the example (4.4 and figures 3/4) of Nabonita's paper.
> 

I don't know, how you have defined "syntactic indexing". But, I understand
"deep structure" as "semantic indexing". Deep structure or facet-based
indexing is very much semantic because here the roles of each concept is
analysed and identified roles/facets are ordered in a helpful order. Again,
the helpfulness of sequence can be decided according to the user community
or type of information resource. Ideally speaking, for
interoperability/mapping, the facet analysis and coordination should be
based on some well defined principles. 

On the contrary in syntactic indexing, the concepts are loosely coordinate
to each other without any role definition, as in the case of UDC. In UDC,
the classes are related but one can't identify that what kind of relation is
there between the two concepts.

In my present work I tried to address the issue of concept coordination in
SKOS. An ordered set of concepts where each component has a role and a well
defined relation between two concept. The coordination method presented is
especially meant for concepts derived from vocabulary control tools such as
thesauri, taxonomy. etc.



> 
> The example presents a document that is
> 
> 1. in the DISCIPLINE of "Medicine"
> 2. about the ENTITY "Human Body"
> 3. about a "Disease" that is a PROPERTY of the "Human Body"
> 4. about the ACTION of "Treatment" of the "Disease"
> 5. about the TYPE of "Radiation Therapy" for this "Treatment"
> 6. about the TOOL "Ionized Packet Chamber" for "Radiation Therapy"
> 7. about the ENTITY "X-Ray" in "Radiation Therapy"
> 8. about the APPLICATION "Radiation Technique" of "Radiation Therapy"
> 
> Well, the example could be more convincing but anyway: We don't need new
> properties and classes in SKOS for that kind of indexing. You should
> create a new ontology with DISCIPLINE, ENTITY, ACTION, TYPE,
> APPLICATION, and METHOD and derive these properties from skos:subject
> instead of trying to put them into SKOS. By the way the properties
> 
Creating a new ontology is not my objective. Rather to resolve the
outstanding issues in the existing ontologies or knowledge organization
systems. Now the SKOS user group has to decide that to resolve the issue of
coordination, these classes are acceptable in SKOS or not.



> skos:primarySubject
> skos:isPrimarySubjectOf
> 
> should also be skipped (do you read this Mike? ;-) because they are not
> well defined (what is "primary"? why isn't there a "secondary"? or
> "third?" What about weighted index terms?
> 
I also think that the utility of the primarySubject property class has to be
defined properly.



> To support syntactic indexing in SKOS first the Coordination issue needs
> to be solved. And I am not sure whether syntactic indexing is really an
> SKOS issue. The most important is maybe *ordered sets* of index terms. I
> think grouping with skos:coordination and skos:orderedCoordination is
> enough but more complex realtions between index term need te be
> described with additional RDF statements. See also our discussion
> "Example of coordination with DDC" in August 2006 at this list.
> 

If we are talking about coordination, we can either mean syntactic or
semantic one. Obviously, RDF is meant to bring semantics, hence, semantic
coordination will be preferred.

"Coordination" is nothing but establishing *ordered set* of index terms /
subject components. Classification schemes like DDC are not meant for
concept coordination  or *Ordering*. UDC is on principle based on DDC kind
of enumeration but allows loose coordination. Hence, more a kind of
syntactic style of indexing system.



> P.S: By the way you XML representation of SKOS in figure 3 is broken
> (not well formed XML). You should always validate.
> 
I'm trying to fix the schema and validating it.


> P.P.S: What's the state of skos:Notation and skos:Coordination?
> 

Based on my analysis on the limitations of classificatory notation as a
library science professional, I've my own apprehensions in the use of
classificatory notation in SKOS.

Thanks once again for the feedbacks,

Nabonita
-- 
View this message in context: http://www.nabble.com/Comments-on-SKOS-Extension-for-Sub.-Indexing-tf2966088.html#a8811465
Sent from the w3.org - public-esw-thes mailing list archive at Nabble.com.

Received on Monday, 5 February 2007 18:02:36 UTC