RE: Proposal for a SPEK vocabulary ...

Hello all

Thanks to Leonard's remarks I've come up over the week-end with a new version of SPEK.
It's on-line at the same adddress
http://www.mondeca.com/lab/bernard/spek.rdf
For those who missed the first cut or would like to track changes, the v0 is still on-line
http://www.mondeca.com/lab/bernard/spekv0.rdf

Actually I meant to publish it earlier yesterday and post to the list, but unfortunately,
mondeca.com server happens to be physically in Florida, and has been soaked by Wilma
yesterday afternoon. So we had about 24 hours off-line ... so is life in a connected world
... But it seems to be OK now, I must say sooner than expected. People overthere become
amazingly efficient when coping with those repetitive disasters.

Anyway, some words about this new version.

I have got rid of the controversial "usedTerm" and "forConcept" properties, which were
there before I figured out how to introduce hubjects, and are actually useless (and maybe
meaningless).

I've completely changed and revisited the examples, making them hopefully less misleading
and less prone to controversial interpretations, and used more namespaces to make
perspectives and aspects more distinct from each other. I tried to stress in this example
the following points:

- The same resource, e.g. the same skos:Concept, can be used in different perspectives to
provide different aspects, each using only part of the properties declared by their common
(re)source. See examples 2 and 3.

- Some resources defined outside the skos vocabulary and namespace, like example 1, can
also provide aspects.

- Being or not aspects of the same resource, different aspects can be declared as
expressions of the same subject by means of a connecting hubject.

I have other examples in mind I will add as soon as I sort them out clearly, including
aspects that present the same resource in conflicting ways.

More feedback welcome on this version

Bernard

----------------------------------
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 Leonard Will
> Envoyé : samedi 22 octobre 2005 23:06
> À : public-esw-thes@w3.org
> Objet : Re: Proposal for a SPEK vocabulary RE: Subjects and perspectives
> in SKOS : the jack of all trades ...
>
>
>
> In message <GOEIKOOAMJONEFCANOKCAEHAHBAA.bernard.vatant@mondeca.com> on
> Fri, 21 Oct 2005, Bernard Vatant <bernard.vatant@mondeca.com> wrote
>
> >don't forget that all the point of aspects and perspectives is to make
> >the notion of "valid" or "invalid" relationships *specific to a
> >perspective*.
>
> Bernard -
>
> Sorry not to have grasped exactly what you are proposing, but perhaps
> pursuing these examples a bit further may help understanding.
> >
> >> At present it appears to me that you have the relationships (if I may
> >> avoid the complexity of RDF by expressing them in a variation of
> >> conventional thesaurus form, assuming English as the default language):
> >
> >> Wetness
> >> fr      Humidité
> >> UF-fr   Hygrométrie
> >> UF      Moisture
> >> BT      Measurement
> >>         Hygrometry
> >
> >OK ... except for the last one. Agreed, you have to look closely at the
> >code to see that, but "Hygrometry" is not defined as an instance of
> >skos:Concept, but of spek:Term (actually maybe I should have defined
> >this class in another namespace). The semantics of the property
> >"usedTerm" is maybe unclear, but it intends to provide a bridge between
> >the SKOS framework where terms are attributes of concepts, and another
> >yet to be completely specified, where "Term" is a class (allowing e.g.
> >to put notes on synonyms, and so on)
> >
> >So ex:Hygrometry does not fit in the Thesaurus framework, and actually
> >you don't see it at all in the Thesaurus perspective.
>
> Well, yes, the semantics are not at all clear to me. As far as I can see
> from your proposal, "usedTerm" has the definition "A term expressing the
> concept". If this does not mean "A term that may be used to label the
> concept", I'm not sure what it does mean. Is it perhaps "A term that
> involves this concept in its definition" or "A term which is used in the
> definition of this concept"?
>
> The converse relationship, "forConcept", defined as "The concept
> expressed by this term" similarly seems to me only to be meaningful if
> defined as "A concept which can be labelled by this term".
>
> Can you clarify what "expressing" means, if possible?
>
> >> Measurement
> >> UF      Measure
> >> NT      Wetness
> >
> >OK
> >
> >> Hygrometry
> >> fr      Hygrométrie
> >> UF      Moisture level
> >> UF-fr   Taux d'humidité
> >> DEF-fr  Mesure du taux d'humidité dans l'atmosphère
> >> DEF     Measurement of the moisture level in the atmosphere
> >
> >> Wetness is a property of materials, and not a kind, part or instance of
> >> the activity "measurement" or of the material "moisture".
> >
> >Hmm. Not sure I follow you completely, but you are certainly right.
>
> Therefore, "moisture" should not be specified as an "altLabel" (i.e. UF)
> for "wetness" and  "measurement" should not be specified as a broader
> term for "wetness".
> >
> >> Hygrometry is an activity, and therefore could be considered a kind of
> >> measurement, but it is not a broader term of the property measured.
> >
> >Look more closely :)
> >It is not declared as such, actually. As said above, it belongs to a different
> >perspective.
>
> My note above requesting clarification of "expressing" applies here too.
>
> >> "Measure" is ambiguous - it might be the result of a measurement
> >> activity, or a measuring instrument, or a part of the verb "to measure",
> >> not normally acceptable in a thesaurus.
> >
> >OK
> >
> >> If you want to retain this example, a better set of relationships would
> >> be:
> >
> >> wetness
> >> UF      humidity
> >>         moisture level
> >>         dryness
> >
> >I'm amazed to see dryness as a synonym of wetness, but so be it ...
> It's actually an example used in thesaurus construction standards - both
> "dryness" and "wetness" express the concept of "moisture content", so
> can be treated as equivalent. It's the issue of whether a glass is half
> empty or half full . . .
> >
> >> UF-fr   humidité
> >>         taux d'humidité
> >
> >OK
> >
> >> RT      moisture
> >>         hygrometry
> >
> >No, hygrometry is *not* a related concept.
>
> Well, logically it is, though perhaps you have not defined it as such.
>
> >> measurement
> >> NT      hygrometry
> >> NT-fr   hygrométrie
> >>
> >> hygrometry
> >> fr      hygrométrie
> >> BT      measurement
> >> RT      wetness
> >>         moisture
> >> DEF     Measurement of the moisture level in the atmosphere
> >> DEF-fr  Mesure du taux d'humidité dans l'atmosphère
> >>
> >> moisture
> >> RT      wetness
> >>         hygrometry
> >
> >Same remarks here. All you write above boils down to try and put
> >"hygrometry" is the same perspective as "wetness", the unique Thesaurus
> >perspective. It's exactly what SPEK wants to avoid :(
>
> A thesaurus perspective would certainly wish to include these two
> concepts (or terms, if you wish). Are you saying that some of these
> would not occur in a thesaurus?
>
> Sorry, but I'm afraid that I am not convinced that this approach of
> combining different perspectives is really helpful. You can have a list
> of terms and a list of concepts and there are many-to-many relationships
> between them.
>
> In a thesaurus, several terms may represent a single concept, one of
> these terms being chosen as "preferred" and the others being
> "non-preferred". Any given term can represent only one concept, as
> defined in its scope note. Terms that might represent more than one
> concept are distinguished by the addition of parenthetical qualifiers.
>
> In a terminological database, or a dictionary, as I understand it, a
> single term may represent many concepts, and these are given in a series
> of definitions. In this case the different meanings of the terms are
> often numbered or lettered. When the term is encountered in isolation it
> is not possible to know which meaning is intended; context is necessary
> for this, so entries in a terminological database cannot be used as
> isolated metadata elements to express the subjects of documents.
>
> These two types of structure, linking terms and concepts in two
> different ways, have different purposes and structures, and I agree with
> Stella that "it is dangerous to expect the same model to work for
> several different applications".  I would have to see some realistic
> "use cases" to be convinced that it is helpful, rather than confusing,
> to combine them.
>
> >I agree they have to be improved or completely changed. Actually I
> >built on an example in the SKOS Guide, maybe it was not a good idea.
>
> I'll be interested to see any further examples that may help me to
> understand how your proposals would work in practice.
>
> Best wishes
>
> Leonard
>
>
> --
> Willpower Information       (Partners: Dr Leonard D Will, Sheena E Will)
> Information Management Consultants              Tel: +44 (0)20 8372 0092
> 27 Calshot Way, Enfield, Middlesex EN2 7BQ, UK. Fax: +44 (0)870 051 7276
> L.Will@Willpowerinfo.co.uk               Sheena.Will@Willpowerinfo.co.uk
> ---------------- <URL:http://www.willpowerinfo.co.uk/> -----------------
>

Received on Tuesday, 25 October 2005 14:28:38 UTC