Hi Dave,
Thanks for the heads up on the <rdf:li> property, that does need changing I
think.
To explain why I did what I did ...
Let's say I have concept A from thesaurus T1, and concepts B and C from
thesaurus T2. I also have a document collection D which has been indexed
against concepts from T2.
Somebody tells me that 'concept A is exactly equivalent to concepts B and
C.'
If I interpret this to mean that 'the set of resources that are about
concept A is identical to the intersection of the set of resources that are
about concept B and the set of resources that are about concept C' I have
some useful information about how to transform queries. Now if somebody
asks for documents from D that are about concept A, I can transform this
into a query in terms of B and C and guarantee accurate results.
So I'm saying the best way to interpret equivalence expressions is as being
set-like. They do imply something about sets, but the concepts themselves
are not the sets, the sets are the sets of resources that are about the
concepts.
This is the interpretation taken by Doerr
<http://jodi.ecs.soton.ac.uk/Articles/v01/i08/Doerr/>.
Now if I say something like ...
<soks:Concept rdf:about="#A">
<owl:equivalentClass rdf:parseType="resource">
<owl:intersectionOf rdf:parseType="collection">
<soks:Concept rdf:about="#B"/>
<soks:Concept rdf:about="#C"/>
</owl:intersectionOf>
</owl:equivalentClass>
</soks:Concept>
... I am in fact saying something about the things that are true instances
of the concepts. That is, things with the property <rdf:type> pointing to
the concepts.
There are two problems with this:
1. I don't have the information I need in order to be able to guarantee
recall of documents after query transformation.
2. Many concepts should not be modelled as <owl:Class>es. The concept
'Running' is not a class. The concept 'Java programming language version
1.4.2' is not a class. The concept 'fish and chips' is not a class. Yet
all these may be concepts in a thesaurus. If a concept is not a class, we
can't use it as the subject or object of OWL set based expressions.
However, you can use OWL to make statements about the sets of things that
are 'about' some concept. Hence the restrictions over things with property
<dc:subject>. What I'm trying to say is, this is what equivalence
expressions are best taken to mean. Then we avoid hazy philosophical
questions and just end up with useful information about how to transform
queries.
Does this change your opinion?
Al.
> -----Original Message-----
> From: Dave Reynolds [mailto:der@hplb.hpl.hp.com]
> Sent: 27 November 2003 14:41
> To: Miles, AJ (Alistair)
> Cc: 'public-esw-thes@w3.org'
> Subject: Re: FW: SKOS-Mapping and OWL - set based constructs
>
>
>
> Hi Alistair,
>
> > What do you think of this?
>
> This does not sound like a good idea.
>
> [Apologies - I haven't had time to look at the mapping
> proposal yet so
> these comments are based purely on the quoted message and I
> might have got
> hold of the wrong end of the stick ...]
>
> First, I'd expect you to translate the soks AND into an OWL
> intersectionOf
> over the concepts not over restrictions on dc:subject.
>
> Second, I don't see the argument that these constructs are
> more "intuitive"
> than the OWL equivalents. If they are truly equivalent and
> all you've
> done is change the name then that doesn't seem helpful.
>
> Third, it's not a good idea to use rdf:li here. The OWL
> constructs use
> parseType collection for very good reasons (to express a
> closed collection
> which can't be messed up semantically by later assertions).
>
> Dave
>
> Miles, AJ (Alistair) wrote:
>
> > The idea is that the skos-mapping constructs are a more
> convenient and
> > intuitive shorthand for more formal set based constructs
> that could be
> > expressed in OWL.
> >
> > So for example, you may consider that statements such as ...
> >
> > <soks:Concept rdf:about="#A">
> > <soks-map:broaderMatch>
> > <soks-map:AND>
> > <rdf:li rdf:resource="#B"/>
> > <rdf:li rdf:resource="#C"/>
> > </soks-map:AND>
> > </soks-map:broaderMatch>
> > </soks:Concept>
> >
> > ... are in fact a convenient shorthand for the statements ...
> >
> > <owl:Restriction>
> > <owl:onProperty rdf:resource="&dc;subject"/>
> > <owl:hasValue rdf:resource="#A"/>
> > <rdfs:subClassOf rdf:parseType="resource">
> > <owl:intersectionOf rdf:parseType="collection">
> > <owl:Restriction>
> > <owl:onProperty rdf:resource="&dc;subject"/>
> > <owl:hasValue rdf:resource="#B"/>
> > </owl:Restriction>
> > <owl:Restriction>
> > <owl:onProperty rdf:resource="&dc;subject"/>
> > <owl:hasValue rdf:resource="#C"/>
> > </owl:Restriction>
> > </owl:intersectionOf>
> > </rdfs:subClassOf>
> > </owl:Restriction>
> >
> > For further discussion of this problem, see the extended
> writeup of open
> > design issues on the SWAD RDF Thesaurus wiki (Issue 9 -
> Inter-thesaurus
> > mapping) <http://esw.w3.org/topic/RdfThesaurus>.
> >
> > What do you think of this?
> >
> > Yours,
> >
> > Alistair.
> >
> >
> >
> >>-----Original Message-----
> >>From: ewallace@cme.nist.gov [mailto:ewallace@cme.nist.gov]
> >>Sent: 26 November 2003 18:59
> >>To: A.J.Miles@rl.ac.uk
> >>Subject: Re: SKOS-Mapping comments and labels added
> >>
> >>
> >>
> >>You wrote:
> >>
> >>
> >>>Comments and labels have been added to the SKOS-Mapping vocabulary.
> >>>
> >>><http://www.w3c.rl.ac.uk/2003/11/21-skos-mapping>
> >>
> >>This file contains AND, OR, and NOT properties which mimic OWL
> >>vocabulary elements: owl:intersectionOf, owl:unionOf, and
> >>owl:complementOf respectively. Why invent new terms?
> >>
> >>-Evan
> >>
> >>Evan K. Wallace
> >>Manufacturing Systems Integration Division
> >>NIST
> >>
> >>
> >
> >
>