Creating a terminology extension for SKOS

Hi, Miles, et al.,
This response opens up an interesting set of issues. Laurent Romary, who is
the designer of our MDR is indeed using rdf notation to specify the data
categories themselves, but we haven't explored the issues involved in
expressing the whole of the TMF in rdf -- or at least not that I have seen.
However, Laurent tells me that he's been working on a crosswalk for the
concept-system-related data categories more or less in parallel with the
work that Alan, Gerhard Budin and I did in just mapping the data categories
to SKOS components. It wouldn't surprise me if Laurent's stuff is expressed
or could be expressed in rdf. All this does indeed need to become part of
the upcoming TC 37 expanded work on concept systems, which is slated to use
a good deal of UML modeling. The question arises in my mid how far we want
to go with this. I've been focused on the data categories that reflect
concept relations and semantic content. There's also a huge amount of
so-called administrative data and other informational data included in many
terminology systems that may or may not be relevant to interoperability
between various concept schemes, but which may well be the content that
people are looking for when they follow these leads into the terminological
environment.
 Bye for now
Sue Ellen

 On 10/11/05, Miles, AJ (Alistair) <A.J.Miles@rl.ac.uk> wrote:
>
> Hi Alan,
>  See http://lists.w3.org/Archives/Public/public-esw-thes/2005Oct/0078.html
>  Btw I'm beginning to think that the best course of action regarding SKOS
> & terminologies work would be for TC37 to figure out how to express its
> underlying model for terminologies using RDF(S) and OWL, as a rough draft,
> and then we can look at mapping that to SKOS Core via refinements,
> equivalences and mapping rules. I think the exercise would help to make
> explicit a lot of the assumptions that TMF makes about its underlying data
> model.
>  Fwiw a couple of comments re TMF [1] and the current state of the art:
>  TMF has a laudable goal: to integrate XML markup languages for
> terminological data by expressing a common meta-model. Each markup language
> can then be seen as an expression of that meta-model, and thus mapped to
> other markup languages.
>  The crux is the modelling paradigm/formalism that TMF uses to express
> that meta-model. The formalism used by TMF talks about a 'hierarchy of
> information levels', and uses the notion of a 'data category' extensively.
> It's not clear how this formalism relates to other well established
> formalisms such as UML or RDF(S). We can't even begin to compare SKOS to
> TMF until we are all talking the same basic language (i.e. using the same
> modelling formalism).
>  So, that said, I'd like to try to persuade you to use the RDF(S)
> modelling formalism to express your meta-model :) A couple of reasons:
>   - in TMF, 'data categories' are used to create what are essentially
> attribute/value pairs. The notion of a 'statement', which is common both to
> RDF [2] and to the DCMI abstract model [3], takes the attribute/value pairs
> idea further. A 'statement' gives not only an attribute/value pair, but also
> gives the 'subject' (i.e. the thing) that the attribute value pair applies
> to. When you try to intepret attribute/value pairs in the context of TMF,
> the unanswered question is: 'What exactly do these attribute/value pairs
> apply to? I.e. What are these statements *about*?'
>   - 'data categories' roughly correspond to the notion of 'properties' or
> 'predicates' in RDF. However, data categories are identified only by a
> string, giving no clear way to disambiguate in the case where two categories
> from different sources use the same name. Within RDF, the fundamental way of
> identifying and disambiguating properties is to give them URIs. This
> guarantees interoperability beyond closed information environments, i.e.
> on the web. Furthermore, the formalism of RDF can be used to describe the
> properties themselves, including the operational characteristics of those
> properties, in a way that can be automatically handled by computer programs.
>
>  To cut a long story short, I think that if you continue to refine the
> notions of 'hierarchical information levels' and 'data categories' in
> response to the demands of a distributed information environment, you're
> going to re-invent something very much like RDF anyway, so you might as well
> start using it now and save yourself the effort :)
>  I'd be very interested to know what you think of the above, especially
> whether it makes any sense at all.
>  But back to the current review ... any comments on, relating to the
> changes discussed at this review [4]:
>  http://www.w3.org/2004/02/skos/core/guide/2005-10-06/
> http://www.w3.org/2004/02/skos/core/spec/2005-10-06/
>  ... before they become W3C Public Working Drafts? (You can still comment
> after they've become public working drafts, but if you've got anything now
> that would be great :)
>  Cheers,
>  Al.
>  [1]
> http://www.loria.fr/projets/TMF/DOC/ISO16642/ISO16642_160802_finale.html
> [2] http://www.w3.org/TR/rdf-primer/
> [3] http://dublincore.org/documents/abstract-model/
> [4] http://www.w3.org/2004/02/skos/core/review-2
>
> -----Original Message-----
> *From:* public-esw-thes-request@w3.org [mailto:
> public-esw-thes-request@w3.org]*On Behalf Of *AlanK Melby
> *Sent:* 11 October 2005 13:22
> *To:* public-esw-thes@w3.org
> *Subject:* Re: pre-coordination + terminology
>
> What is the status of documenting the procedure for creating SKOS
> extensions?
>  Quite a few extensions will be needed in order to handle basic
> terminological concept entries.
>  Alan K Melby
>  = = =
>
> *"Tudhope D S (Comp)" <dstudhope@glam.ac.uk>* wrote:
>
> > It would be good if SKOS could be developed to handle pre-coordinated
>
> > strings, or faceted classification schemes (the problems are the same)
>
> > but that would be quite a substantial extra development.
>
> > Leonard
>
>  Yes, that would be an interesting future project for SKOS Extensions or a
> new SKOS-related schema.
>
>  Doug
>
>


--
Sue Ellen Wright
Institute for Applied Linguistics
Kent State University
Kent OH 44242 USA
sellenwright@gmail.com
swright@kent.edu
sewright@neo.rr.com