RE: Use AND type references

Hi Lori, all,

Thanks alot for this requirement, this is just a note to say that I think we should look to put together a proposal for this for the next review.

I think there's actually two requirements here.  The first is a requirement to be able to assert in index metadata that the subject of a document is not just (cut flowers, crop production) but is in fact (cut flowers + crop production).  This is very similar to the requirement that came from Robert Watkins regarding MeSH and the use of 'qualifiers' (see [1] and subsequent in thread).  Leonard noted in that thread that this is an example of a common problem in post-coordinate indexing systems, regarding false hits.  

My current thinking is something along the lines of allowing indexers to express the subject of a document by building a 'compound concept' on the fly, and then using that compound concept in the metadata expression.

This would require a new class and a new property, e.g. (using notation3):

skos:CompoundConcept a rdfs:Class;
  rdfs:subClassOf skos:Concept;
.

skos:component a rdf:Property;
  rdfs:domain skos:CompoundConcept;
  rdfs:range skos:Concept;
  rdfs:subPropertyOf skos:broader;
.

The idea is that instances of skos:CompoundConcept are blank nodes, and built on-the-fly by indexers.  This would allow expressions like...

<http://somewhere.org/somedoc> skos:subject
  [
    a skos:CompoundConcept;
    skos:component eg:cutflowers;
    skos:component eg:cropproduction;
  ];
.

... which is more expressive than ...

<http://somewhere.org/somedoc> 
  skos:subject eg:cutflowers;
  skos:subject eg:cropproduction;
.

I think Leonard's problem is that currently most databases of subject index metadata allow you to express the second, but not the first.

The neat bit about the above is to make the property skos:compound a sub-prop of skos:broader - which means that query expansion tools running over the closure of skos:broader would automatically show up this result under an expanded search for e.g. 'cut flowers'.

The second requirement is to be able to generate documentation from an un-coordinated concept scheme (i.e. before any indexing has been done) that directs the indexer to build a compound concept as described above.  I.e. given some SKOS data I want to be able to generate e.g.:

cut flower production USE cut flowers 
                          AND crop production

... which is just one possible way of documenting this instruction.  Within a web based system, for example, there could be a hyperlink which when activated generates the compound concept for the indexer (i.e. handles all the database stuff).

I'm not sure how to represent that yet, noting that if you have e.g. (notation3):

eg:cutflowers a skos:Concept;
  skos:prefLabel 'cut flowers';
  skos:altLabel 'cut flower production';
.
  
eg:cropproduction a skos:Concept;
  skos:prefLabel 'crop production';
  skos:altLabel 'cut flower production';
.

... you don't actually have enough information to generate the above indexing instruction.

I.e. if you have a literal which turns up as an alternative label for more than one concept, you don't know whether to generate an 'AND' or an 'OR' type instruction for the indexer.

You could do something like e.g.

[] a skos:CompoundConcept;
  skos:component eg:cutflowers;
  skos:component eg:cropproduction;
  skos:altLabel 'cut flower production';
.

... which is essentially the same as Bernard's suggestion.  A potential problem with this is that you are actually pre-coordinating concepts, and the basic point of a post-coordinate scheme is that you can co-ordinate on-the-fly as you index. 

Anyway, just mooting some thoughts, I haven't really thought it through properly, and not sure I fully understand the problem yet.  But I'm sure we can find a solution, the job will be to make sure it fits with everything else :)

Cheers for now,

Al.

[1] http://lists.w3.org/Archives/Public/public-esw-thes/2005Jul/0028.html

   



> -----Original Message-----
> From: public-esw-thes-request@w3.org
> [mailto:public-esw-thes-request@w3.org]On Behalf Of Lori Finch
> Sent: 28 September 2005 14:07
> To: Bernard Vatant; public-esw-thes@w3.org
> Subject: RE: Use AND type references
> 
> 
> 
> Bernard,
> 
> Hmmm...  since "cut flower production" is a concept, but actually
> expressed by two preferred terms, I am glad to see that your 
> new idea is
> to have it as a subclass of Concept.  That is logical to me.
> 
> Simple is good and it makes sense.
> 
> Thanks for your reply!  
> Good to hear from Stella too!
> 
> Lori
> 
> 
> -----Original Message-----
> From: Bernard Vatant [mailto:bernard.vatant@mondeca.com] 
> Sent: Wednesday, September 28, 2005 8:41 AM
> To: Lori Finch; public-esw-thes@w3.org
> Subject: RE: Use AND type references
> 
> 
> Second thoughts ...
> 
> > Note that skos:AND-Concept is not a subclass of skos:Concept,
> > since it does not bear prefLabel
> 
> Thinking about it, skos:prefLabel is *not* mandatory for skos:Concept.
> 
> So maybe we do not even need a particular class for the AND concepts
> but simply use blank skos:Concept nodes.
> 
> <skos:Concept rdf:ID="foo">
> 	<skos:AND rdf:parseType="Collection">
> 		<skos:Concept rdf:about="http://thes.org#cut_flowers"/>
> 		<skos:Concept
> rdf:about="http://thes.org#crop_production"/>
> 	</skos:AND>
> 	<skos:altLabel>cut flower production</skos:altLabel>
> </skos:Concept>
> 
> Maybe too simple to be true :)
> 
> > -----Message d'origine-----
> > De : public-esw-thes-request@w3.org
> > [mailto:public-esw-thes-request@w3.org]De la part de Bernard Vatant
> > Envoye : mercredi 28 septembre 2005 13:13
> > A : Lori Finch; public-esw-thes@w3.org
> > Objet : RE: Use AND type references
> >
> >
> >
> > Just some ideas - do not know what Alistair has in store about it.
> >
> > 1. You do not want to create an explicit descriptor for 
> "cut flowers"
> AND "crop
> > production".
> > 2. But you want anyway to hang the alternative label "cut flower
> production" to some
> > resource.
> > 3. Actually ("cut flowers" AND "crop production") is a concept
> >
> > What comes to mind is to use "blank concept", defined by some "AND"
> operator defined in
> > the SKOS namespace.
> > Something like
> >
> > <skos:AND-Concept rdf:ID="foo">
> > 	<skos:AND rdf:parseType="Collection">
> > 		<skos:Concept rdf:about="http://thes.org#cut_flowers"/>
> > 		<skos:Concept
> rdf:about="http://thes.org#crop_production"/>
> > 	</skos:AND>
> > 	<skos:altLabel>cut flower production</skos:altLabel>
> > </skos:AND-Concept>
> >
> > Note that skos:AND-Concept is not a subclass of 
> skos:Concept, since it
> does not bear
> > prefLabel
> >
> > How does that fly?
> >
> > ----------------------------------
> > Bernard Vatant
> > Mondeca Knowledge Engineering
> > bernard.vatant@mondeca.com
> > (+33) 0871 488 459
> >
> > http://www.mondeca.com
> > http://universimmedia.blogspot.com
> > ----------------------------------
> > -----Message d'origine-----
> > De : public-esw-thes-request@w3.org
> [mailto:public-esw-thes-request@w3.org]De la part de
> > Lori Finch
> > Envoye : mardi 27 septembre 2005 22:06
> > A : public-esw-thes@w3.org
> > Objet : Use AND type references
> >
> >
> > Pardon if this was already discussed -
> >
> > I don't see an accommodation of USE "AND-TYPE" cross 
> references in the
> SKOS core nor in
> > the SKOS Extensions.
> >
> > An example of AND-type cross reference in thesauri:
> >
> > cut flower production USE cut flowers
> >                                AND crop production
> >
> > This indicates to the indexer and searcher to use both preferred
> terms, "cut flower" AND
> > "crop production" for indexing and retrieval of the concept "cut
> flower production".
> >
> > For NISO Z39.19 thesaurus standard, this is section 8.2.5.
> "Cross-references to Elements
> > of Compound Terms"
> >
> > Any previous discussion or suggestions for how these can be 
> handled in
> SKOS?
> >
> > Thanks,
> > Lori
> >
> > Lori J. Finch
> > Thesaurus Coordinator
> > National Agricultural Library
> > 10301 Baltimore Avenue
> > Beltsville, MD 20705
> > 301-504-6853
> > NAL Agricultural Thesaurus: http://agclass.nal.usda.gov/agt/agt.htm
> >
> >
> >
> >
> 
> 
> 
> 
> 
> 
>

Received on Wednesday, 28 September 2005 16:52:28 UTC