RE: Label management information in SKOS-XL (continuing from UMTHES and SKOS-XL)

[Thomas Bandholtz]

Hi Christophe, Johan, Leonard, and others,

"SKOS / ISO 25964 interchangeability" should be seen as a strategic target, as long as this will not *restrict* any future SKOS usage to the ISO patterns.

I really like Christophe's wording:

[Christophe:]
> There is a rather striking difference between SKOS flexibility and extendability
> (opening ways to unstandardized horizons) and ISO willingness
> to build upon the past within a stricter frame.

So, let us leave SKOS as flexible as it is, but let us try to harmonize some recommended SKOS extension for ISO interoperability.

Johan obviously has drafted something like that some tome ago:

[Johan:]
> JDS-3: on an earlier version of SKOS-XL, I made an exercise some time ago to cover the BS8723
> (which was input for the ISO standard)
> JDS-3: note this exercise was never discussed on any forum yet

Johan, have you made this exercise public? It might be a good starting point.


I would like to contribute some of my own considerations about Label management here.

Coordination should be handled in a different thread, as (following Leonard in this regard) coordination might rather be about Concepts, not Labels.

[Leonard:]
> Coordination of concepts has previously been discussed during the development of SKOS
> but was not followed through because it was "too hard" to deal with within the time available, ...

Christophe may see this differently, but I will focus on some basic Label / Term patterns in the following.

Christophe has started this thread with one concise example:

[Christophe:]
> Looking at ISO 25964, I have:
> Attributes of ThesaurusTerm:
> LexicalValue String      1 The wording of the term
> identifier   String      1 A unique identifier for the term
> created      date     0..1 The date when the term was created
> modified     date     0..1 The date when the term was last modified
> source       String   0..1 The person(s) or document(s) from which the term was taken
> Status       String   0..1 Indication of whether the term is candidate, approved, etc.
> lang         language 0..1 A code showing the language of the term. This should be
                           included if the thesaurus supports more than one language

To me this looks rather simple. These attributes may be mapped as follows:

iso:lexicalValue -> skosxl:literalForm
iso:identifier: -> URI of the Label resource
iso:created, modified, source -> dct:created, etc.
iso:status -> might be expressed as a skos:editorialNote
iso:lang -> RDF language tag attached to the literalForm.

Some of these mapping may be arguable, but I connot find any structural challenge in this example.

Looking at the ISO model provided by Leonard (thanks Leonard for this update!) as well as to the patterns of UMTHES, I find the most crucial difference between SKOS and ISO is about distinguishing preferred terms from-non preferred terms.

SKOS distinguishes xl:prefLabel from xl:altLabel relations, but the related xl:Label itself is unclassified in this regard.
 
Following the SKOS(XL) semantics, one and the same xl:Label may appear as prefLabel of one Concept and as altLabel of another.

SKOS only keeps you from using the same Label as pref and alt in the same Concept:

> SKOS S13: "skos:prefLabel, skos:altLabel and skos:hiddenLabel are pairwise disjoint properties."

This make only one usage pattern unvalid:

# one concept with the same label as pref/alt
# not valid due to S13

<Love> skosxl:prefLabel <love> ;
    skosxl:altLabel <love> .

But the following should be compliant with the explicit SKOS semantics, as far as I see:

# two concepts with reverse pref/alt Labels
# valid in SKOS but unwanted by ISO

<A> skosxl:prefLabel <love>;
    skosxl:altLabel <adoration> .

<B> skosxl:prefLabel <adoration> ;
    skosxl:altLabel <love> .


SKOS pref/alt of a label only exists in the context of a given Concept, while ISO pref/nonPref is bound to a given label (~term).

Further more, SKOS(XL) does not contain any equivalence relation. One might see something similar when looking at a single Concept: the prefLabel of this Concept may be seen as equivalent to the altLabel of the same Concept.

But again, this is not a relation between the two Labels, it is just a usage pattern in the context of a single Concept, and the same two Labels may be used differently in the context of another Concept.

If we want to have something like ISO term specialization & equivalence in a SKOS extension I would draft this as follows:

First, define ext:prefTerm and ext:nonPrefTerm both as subclasses of skosxl:Label.

ext:prefTerm rdfs:subClassOf skosxl:Label .
ext:nonPrefTerm rdfs:subClassOf skosxl:Label .

Now make these two classes disjoint.

ext:prefTerm owl:disjointWith nonPrefTerm .

Declare a subProperty of skosxl:prefLabel with ext:prefTerm in its range (btw. this should be valid in OWL2).

ext:hasPrefTerm rdfs:subProperty skosxl:prefLabel;
    rdfs:range ext:prefTerm .

Declare another subProperty of skosxl:altLabel with ext:nonPrefTerm in its range.

ext:hasNonPrefTerm rdfs:subProperty skosxl:altLabel;
    rdfs:range ext:nonPrefTerm .

Now define use/usedFor both as subProperties of skosxl:labelRelation.

ext:usedFor rdfs:subPropertyOf skosxl:labelRelation;
    rdfs:domain ext:prefTerm;
    rdfs:range ext:nonPrefTerm;
    owl:inverseOf ext:use .

Now you can write:

<love> ext:usedFor <adoration> .

From this will be inferred:

<love> rdf:type ext:prefTerm .
<adoration> rdf:type ext nonPrefTerm .

and

<adoration> ext:use <love> .

Note that all this leaves the existing SKOS semantics untouched, but it provides an extension with more strict semantics:

# not valid:
<A> ext:prefTerm <love>;
    ext:nonPrefTerm <adoration> .

<B> skosxl:prefLabel <adoration> ;
    skosxl:altLabel <love> .

As far as I see, this proposal conforms to the existing SKOS recommendation and (basically) allows expressing some more strict ISO patterns.

I would like to discuss and clarify this so far before moving on to the more complex "compound" and "split" patterns.

What do you think?

Kind regards,
Thomas

[Johan De Smedt]

Hi Thomas,

 

As stated,

- the exercise dates back from end 2008

  (I did update the imports as the SKOS core namespace issue was still 2008/05).

- I made it when reviewing the help my understanding in mapping it to SKOS

- It was never discussed publicly and needs corrections

- It has not been aligned with the recent ISO DIS that was circulated.

 

If it is useful, it can be the start of the exercise suggested by Thomas.

 

Johan.

---

From: public-esw-thes-request@... [mailto:public-esw-thes-request@...] On Behalf Of Thomas Bandholtz
Sent: Thursday, 05 November, 2009 09:32
To: SKOS
Subject: RE: Label management information in SKOS-XL (continuing from UMTHES and SKOS-XL)

Hi Christophe, Johan, Leonard, and others,

"SKOS / ISO 25964 interchangeability" should be seen as a strategic target, as long as this will not *restrict* any future SKOS usage to the ISO patterns.

I really like Christophe's wording:

[Christophe:]
> There is a rather striking difference between SKOS flexibility and extendability
> (opening ways to unstandardized horizons) and ISO willingness
> to build upon the past within a stricter frame.

So, let us leave SKOS as flexible as it is, but let us try to harmonize some recommended SKOS extension for ISO interoperability.

Johan obviously has drafted something like that some tome ago:

[Johan:]
> JDS-3: on an earlier version of SKOS-XL, I made an exercise some time ago to cover the BS8723
> (which was input for the ISO standard)
> JDS-3: note this exercise was never discussed on any forum yet

Johan, have you made this exercise public? It might be a good starting point.


I would like to contribute some of my own considerations about Label management here.

Coordination should be handled in a different thread, as (following Leonard in this regard) coordination might rather be about Concepts, not Labels.

[Leonard:]
> Coordination of concepts has previously been discussed during the development of SKOS
> but was not followed through because it was "too hard" to deal with within the time available, ...

Christophe may see this differently, but I will focus on some basic Label / Term patterns in the following.

Christophe has started this thread with one concise example:

[Christophe:]
> Looking at ISO 25964, I have:
> Attributes of ThesaurusTerm:
> LexicalValue String      1 The wording of the term
> identifier   String      1 A unique identifier for the term
> created      date     0..1 The date when the term was created
> modified     date     0..1 The date when the term was last modified
> source       String   0..1 The person(s) or document(s) from which the term was taken
> Status       String   0..1 Indication of whether the term is candidate, approved, etc.
> lang         language 0..1 A code showing the language of the term. This should be
                           included if the thesaurus supports more than one language

To me this looks rather simple. These attributes may be mapped as follows:

iso:lexicalValue -> skosxl:literalForm
iso:identifier: -> URI of the Label resource
iso:created, modified, source -> dct:created, etc.
iso:status -> might be expressed as a skos:editorialNote
iso:lang -> RDF language tag attached to the literalForm.

Some of these mapping may be arguable, but I connot find any structural challenge in this example.

Looking at the ISO model provided by Leonard (thanks Leonard for this update!) as well as to the patterns of UMTHES, I find the most crucial difference between SKOS and ISO is about distinguishing preferred terms from-non preferred terms.

SKOS distinguishes xl:prefLabel from xl:altLabel relations, but the related xl:Label itself is unclassified in this regard.
 
Following the SKOS(XL) semantics, one and the same xl:Label may appear as prefLabel of one Concept and as altLabel of another.

SKOS only keeps you from using the same Label as pref and alt in the same Concept:

> SKOS S13: "skos:prefLabel, skos:altLabel and skos:hiddenLabel are pairwise disjoint properties."

This make only one usage pattern unvalid:

# one concept with the same label as pref/alt
# not valid due to S13

<Love> skosxl:prefLabel <love> ;
    skosxl:altLabel <love> .

But the following should be compliant with the explicit SKOS semantics, as far as I see:

# two concepts with reverse pref/alt Labels
# valid in SKOS but unwanted by ISO

<A> skosxl:prefLabel <love>;
    skosxl:altLabel <adoration> .

<B> skosxl:prefLabel <adoration> ;
    skosxl:altLabel <love> .


SKOS pref/alt of a label only exists in the context of a given Concept, while ISO pref/nonPref is bound to a given label (~term).

Further more, SKOS(XL) does not contain any equivalence relation. One might see something similar when looking at a single Concept: the prefLabel of this Concept may be seen as equivalent to the altLabel of the same Concept.

But again, this is not a relation between the two Labels, it is just a usage pattern in the context of a single Concept, and the same two Labels may be used differently in the context of another Concept.

If we want to have something like ISO term specialization & equivalence in a SKOS extension I would draft this as follows:

First, define ext:prefTerm and ext:nonPrefTerm both as subclasses of skosxl:Label.

ext:prefTerm rdfs:subClassOf skosxl:Label .
ext:nonPrefTerm rdfs:subClassOf skosxl:Label .

Now make these two classes disjoint.

ext:prefTerm owl:disjointWith nonPrefTerm .

Declare a subProperty of skosxl:prefLabel with ext:prefTerm in its range (btw. this should be valid in OWL2).

ext:hasPrefTerm rdfs:subProperty skosxl:prefLabel;
    rdfs:range ext:prefTerm .

Declare another subProperty of skosxl:altLabel with ext:nonPrefTerm in its range.

ext:hasNonPrefTerm rdfs:subProperty skosxl:altLabel;
    rdfs:range ext:nonPrefTerm .

Now define use/usedFor both as subProperties of skosxl:labelRelation.

ext:usedFor rdfs:subPropertyOf skosxl:labelRelation;
    rdfs:domain ext:prefTerm;
    rdfs:range ext:nonPrefTerm;
    owl:inverseOf ext:use .

Now you can write:

<love> ext:usedFor <adoration> .

From this will be inferred:

<love> rdf:type ext:prefTerm .
<adoration> rdf:type ext nonPrefTerm .

and

<adoration> ext:use <love> .

Note that all this leaves the existing SKOS semantics untouched, but it provides an extension with more strict semantics:

# not valid:
<A> ext:prefTerm <love>;
    ext:nonPrefTerm <adoration> .

<B> skosxl:prefLabel <adoration> ;
    skosxl:altLabel <love> .

As far as I see, this proposal conforms to the existing SKOS recommendation and (basically) allows expressing some more strict ISO patterns.

I would like to discuss and clarify this so far before moving on to the more complex "compound" and "split" patterns.

What do you think?

Kind regards,
Thomas

[Thomas Bandholtz]

Hi Johan,

I think bs8723.owl it is a valid model and a good starting proposal, but
in some aspects I would follow a different approach. Here I find your
OWL model too close to the original UML/XSD (schemas.bs8723.org), so it
does not benefit from the enhanced expressive power of OWL. Let me give
four considerations for today:

(1) bs8723:lexicalValue vs. umt:lexicalVariant

One thing our models have in common (or at least very similar) is adding
lexical properties to xl:Label.
I am talking about bs8723:lexicalValue and umtthes:lexicalVariant. Both
are data properties, not Label relations, and the lexical value (or
variant) itself is not a xl:Label instance, but a simple Literal.

Antoine has argued against this in
http://lists.w3.org/Archives/Public/public-esw-thes/2009Oct/0012.html:
"not attaching that string to an instance of xl:Label using
xl:literalForm prevents you from benefitting from the useful property
chains given in XL. So I would have represented 'wastewater' as an
instance of xl:Label."
Just like the (non-normative) label relation examples in the primer.

I responded that I would not want a property chain for lexicalVariant,
as these are meant to be properties of the Label, not of the related
Concept. This might be arguable, but I see that your bs8723 goes the
same way.

However, there is a little difference:

bs8723:lexicalValue is subProperty of xl:literalForm.
umtthes:lexicalVariant is subProperty of rdfs:Label.

What makes the difference?
Unlike skos:preLabel etc., xl:literalForm is not a subproperty of
rdfs:Label itself.
When someone searches all the rdfs:label incl. subproperties in your
model, this will not include the bs8723:lexicalValue instances.
This finally depends on your intentions.


(2) iso to skos or skos to iso

Whenever mapping between two standards, one can see this from two sides:
looking from iso to skos, or from skos to iso.

I think you model is looking from iso to skos, while mine is looking
from skos to iso.
May be this is even more about looking from UML/XSD to RDF/OWL or vice
versa.

The original BS8723 model (schemas.bs8723.org) is expressed in UML/XSD.
This is why there are so many "association classes". In RDFS/OWL I would
use rdfs:subPropertyOf instead. One example:

# Following bs8723.owl

<mammal> rdf:type bs:ThesaurusConcept .
<cat> rdf:type bs:ThesaurusConcept .

[] rdf:type bs:HierarchicalRelationship ;
    bs:hasBroaderConcept <mammal> ;
    bs:hasNarrowerConcept <cat> ;
    bs:hierarchyType <YourType> .

# end of example 1

Why don't you use skos:broader und skos:narrower?
I guess this is only due to the UML pattern of encoding something like a
sub-property by providing a “hierarchyType” property in an Association
Class. Looking at the http://schemas.bs8723.org examples, they use
"NT", "BT", "BT/BTI", "NT/NTP"  etc. for generic, partitive and instance
hierarchies as hierarchy types.

# In SKOS I would say:

ext:broaderYourType rdfs:subPropertyOf skos:broader;
ext:narrowerYourType rdfs:subPropertyOf skos:narrower;

<mammal> rdf:type skos:Concept;
    ext:narrowerYourType <cat>.
<cat> rdf:type skos:Concept;
    ext:broaderYourType <mammal>.

# end of example 2

The same applies to:
bs8723:AssociativeRelationShip
bs8723:CompoundEquivalence
bs8723:EquivalenceRelationship


(3) Do we need bs8723:ThesaurusConcept as a subclass of skos:Concept?

You see in my last example I silently dropped bs:ThesaurusConcept and
used skos:Concept instead.
bs:ThesaurusConcept is domain of several properties
(bs8723:preferredTerm, bs8723:nonPreferredTerm, etc.) which are not
mandatory, so one might use skos:Concept in the domain as well, or even
rdf:Resource like skos(xl):prefLabel etc. .

Do you really want to say: Anything having a bs:preferredTerm is a
bs:ThesaurusConcept?
(remember discussion about "Using DBpedia resources as skos:Concepts").

Looks like your bs8723 OWL tries to express closed world constraints
just like UML/XSD does.

Why not donate bs:preferredTerm as a property to the open world
(including skos:Concept)?

In this case you would not need a specialized bs:ThesaurusConcept.

The same applies to:
bs8723:Note


(4)  pref / nonPref specialisation of xl:Label

This is in some parts similar to what I have proposed : making a Term
pref or nonPref on its own.
Here I don't really understand the bs8723:CompoundNonPreferredTerm pattern.
Even a PreferredTerm may be compound.

But I guess this is more about coordination.
http://schemas.bs8723.org/ExampleCompounds/Example.xml has an XML example:

<CompoundNonPreferredTerm dc:identifier="3">
<LexicalValue>austenitic chromium manganese steel</LexicalValue>
<dcterms:created>2007-05-24</dcterms:created>
<USE Role="USE +">5</USE>
<USE Role="USE +">6</USE>
<USE Role="USE +">7</USE>
</CompoundNonPreferredTerm>

What if I want "austenitic chromium manganese steel"  to be a
PreferredTerm and then describe the composition?


After all, i think such discussion would benefit from thesaurus instance
examples.

Kind regards,
Thomas

> Hi Thomas,
>  
> As stated,
> - the exercise dates back from end 2008
>   (I did update the imports as the SKOS core namespace issue was still
> 2008/05).
> - I made it when reviewing the help my understanding in mapping it to SKOS
> - It was never discussed publicly and needs corrections
> - It has not been aligned with the recent ISO DIS that was circulated.
>  
> If it is useful, it can be the start of the exercise suggested by Thomas.
>  
> Johan.
>
> ------------------------------------------------------------------------
> *From:* public-esw-thes-request@...
> [mailto:public-esw-thes-request@...] *On Behalf Of *Thomas Bandholtz
> *Sent:* Thursday, 05 November, 2009 09:32
> *To:* SKOS
> *Subject:* RE: Label management information in SKOS-XL (continuing
> from UMTHES and SKOS-XL)
>
> Hi Christophe, Johan, Leonard, and others,
>
> "SKOS / ISO 25964 interchangeability" should be seen as a strategic
> target, as long as this will not *restrict* any future SKOS usage to
> the ISO patterns.
>
> I really like Christophe's wording:
>
> [Christophe:]
> > There is a rather striking difference between SKOS flexibility and
> extendability
> > (opening ways to unstandardized horizons) and ISO willingness
> > to build upon the past within a stricter frame.
>
> So, let us leave SKOS as flexible as it is, but let us try to
> harmonize some recommended SKOS extension for ISO interoperability.
>
> Johan obviously has drafted something like that some tome ago:
>
> [Johan:]
> > JDS-3: on an earlier version of SKOS-XL, I made an exercise some
> time ago to cover the BS8723
> > (which was input for the ISO standard)
> > JDS-3: note this exercise was never discussed on any forum yet
>
> Johan, have you made this exercise public? It might be a good starting
> point.
>
>
> I would like to contribute some of my own considerations about Label
> management here.
>
> Coordination should be handled in a different thread, as (following
> Leonard in this regard) coordination might rather be about Concepts,
> not Labels.
>
> [Leonard:]
> > Coordination of concepts has previously been discussed during the
> development of SKOS
> > but was not followed through because it was "too hard" to deal with
> within the time available, ...
>
> Christophe may see this differently, but I will focus on some basic
> Label / Term patterns in the following.
>
> Christophe has started this thread with one concise example:
>
> [Christophe:]
> > Looking at ISO 25964, I have:
> > Attributes of ThesaurusTerm:
> > LexicalValue String      1 The wording of the term
> > identifier   String      1 A unique identifier for the term
> > created      date     0..1 The date when the term was created
> > modified     date     0..1 The date when the term was last modified
> > source       String   0..1 The person(s) or document(s) from which
> the term was taken
> > Status       String   0..1 Indication of whether the term is
> candidate, approved, etc.
> > lang         language 0..1 A code showing the language of the term.
> This should be
>                            included if the thesaurus supports more
> than one language
>
> To me this looks rather simple. These attributes may be mapped as follows:
>
> iso:lexicalValue -> skosxl:literalForm
> iso:identifier: -> URI of the Label resource
> iso:created, modified, source -> dct:created, etc.
> iso:status -> might be expressed as a skos:editorialNote
> iso:lang -> RDF language tag attached to the literalForm.
>
> Some of these mapping may be arguable, but I connot find any
> structural challenge in this example.
>
> Looking at the ISO model provided by Leonard (thanks Leonard for this
> update!) as well as to the patterns of UMTHES, I find the most crucial
> difference between SKOS and ISO is about distinguishing preferred
> terms from-non preferred terms.
>
> SKOS distinguishes xl:prefLabel from xl:altLabel relations, but the
> related xl:Label itself is unclassified in this regard.
>  
> Following the SKOS(XL) semantics, one and the same xl:Label may appear
> as prefLabel of one Concept and as altLabel of another.
>
> SKOS only keeps you from using the same Label as pref and alt in the
> same Concept:
>
> > SKOS S13: "skos:prefLabel, skos:altLabel and skos:hiddenLabel are
> pairwise disjoint properties."
>
> This make only one usage pattern unvalid:
>
> # one concept with the same label as pref/alt
> # not valid due to S13
>
> <Love> skosxl:prefLabel <love> ;
>     skosxl:altLabel <love> .
>
> But the following should be compliant with the explicit SKOS
> semantics, as far as I see:
>
> # two concepts with reverse pref/alt Labels
> # valid in SKOS but unwanted by ISO
>
> <A> skosxl:prefLabel <love>;
>     skosxl:altLabel <adoration> .
>
> <B> skosxl:prefLabel <adoration> ;
>     skosxl:altLabel <love> .
>
>
> SKOS pref/alt of a label only exists in the context of a given
> Concept, while ISO pref/nonPref is bound to a given label (~term).
>
> Further more, SKOS(XL) does not contain any equivalence relation. One
> might see something similar when looking at a single Concept: the
> prefLabel of this Concept may be seen as equivalent to the altLabel of
> the same Concept.
>
> But again, this is not a relation between the two Labels, it is just a
> usage pattern in the context of a single Concept, and the same two
> Labels may be used differently in the context of another Concept.
>
> If we want to have something like ISO term specialization &
> equivalence in a SKOS extension I would draft this as follows:
>
> First, define ext:prefTerm and ext:nonPrefTerm both as subclasses of
> skosxl:Label.
>
> ext:prefTerm rdfs:subClassOf skosxl:Label .
> ext:nonPrefTerm rdfs:subClassOf skosxl:Label .
>
> Now make these two classes disjoint.
>
> ext:prefTerm owl:disjointWith nonPrefTerm .
>
> Declare a subProperty of skosxl:prefLabel with ext:prefTerm in its
> range (btw. this should be valid in OWL2).
>
> ext:hasPrefTerm rdfs:subProperty skosxl:prefLabel;
>     rdfs:range ext:prefTerm .
>
> Declare another subProperty of skosxl:altLabel with ext:nonPrefTerm in
> its range.
>
> ext:hasNonPrefTerm rdfs:subProperty skosxl:altLabel;
>     rdfs:range ext:nonPrefTerm .
>
> Now define use/usedFor both as subProperties of skosxl:labelRelation.
>
> ext:usedFor rdfs:subPropertyOf skosxl:labelRelation;
>     rdfs:domain ext:prefTerm;
>     rdfs:range ext:nonPrefTerm;
>     owl:inverseOf ext:use .
>
> Now you can write:
>
> <love> ext:usedFor <adoration> .
>
> From this will be inferred:
>
> <love> rdf:type ext:prefTerm .
> <adoration> rdf:type ext nonPrefTerm .
>
> and
>
> <adoration> ext:use <love> .
>
> Note that all this leaves the existing SKOS semantics untouched, but
> it provides an extension with more strict semantics:
>
> # not valid:
> <A> ext:prefTerm <love>;
>     ext:nonPrefTerm <adoration> .
>
> <B> ext:prefTerm <adoration> ;
>     ext:nonPrefTerm <love> .
>
> As far as I see, this proposal conforms to the existing SKOS
> recommendation and (basically) allows expressing some more strict ISO
> patterns.
>
> I would like to discuss and clarify this so far before moving on to
> the more complex "compound" and "split" patterns.
>
> What do you think?
>
> Kind regards,
> Thomas
> --
> Thomas Bandholtz, thomas.bandholtz@..., http://www.innoq.com 
> innoQ Deutschland GmbH, Halskestr. 17, D-40880 Ratingen, Germany
> Phone: [phone] Mobile: [phone] Fax: [phone]
>  

[Johan De Smedt]

Hi Thomas,

Thanks for your many remarks.
I think different threads could start from here and I will come back on
those at the of this reply.

Before reading my in-line remarks I want to make clear what my practice area
is and the general conclusion I make from it.

The objectives my clients have is:
- to be able to build (simple) knowledge organization systems (taxonomy,
SHL, thesauri, ...)
  for specific business area. Legal and jurisprudence, HR, environment and
security, ...
  They all do this with systems predating the "SKOS" standard.
- Publish these KOS to a community directly or indirectly active in the same
business area.
  Each community member typically has his own (simple) KO systems.
- Make matching and mapping relationships between the KOS of different
community members.
  Some matching relationships will be as in the SKOS standard, some
requiring boolean operators.
  (Other mapping relationships will go beyond this. They require dedicated
OWL constructs.)
  In practice, the matchings and mappings are in one way, not 2-way.
- Supply indexing and search engines with the appropriate information, so my
clients can
  provide services such as:
  - providing access (via search) to documents indexed by different
community partners.
My conclusions:
- SKOS/-XL is a common denominator.  Community partners are expected to deal
with them.
  The options are to deal with them at one of the following levels:
  - SKOS
  - SKOS-XL
  - an OWL/RDF extension to SKOS
  - a dedicated format
- As the ISO standard provides a lot more detail in some areas, we can:
  - use ISO upcoming standard in the future
  - use a SKOS extension that captures this in a standardized way
  - use dedicated or business specific extensions
- My preference currently goes to the second option but practice forces me
to use the third.
  - ISO standard is not final (but maybe this group can start something)
  - It is relatively easy to build translators for SKOS or specific SKOS
extensions
- I see benefit in capturing the ISO standard
  - in SKOS or SKOS-XL
    (at least we could follow a common guideline when down-translating a
rich "non SKOS" to SKOS)
  - in a standard SKOS extension

Starting different discussion threads:
- SKOS thesaurus extensions:
  If there is interest I think this must be coordinated with the ISO
thesaurus standards group.
  We may do like extensions for SHL, Taxonomy, ...
  Points of interest I've seen (from the top of my head)
  - pre-coordination (Leonard Will signaled interest)
  - facet vs. concept-group
  - specializing associations
  - relation to text processing; vocabulary management
- Application of SKOS and open world consequences
  (possibly a lot has been said already and the SKOS reference and primer
already talk about it)
  See your point (3) below.
 

kr, Johan De Smedt.
===================

> -----Original Message-----
> From: Thomas Bandholtz [mailto:thomas.bandholtz@...]
> Sent: Sunday, 08 November, 2009 19:31
> To: Johan De Smedt
> Cc: SKOS
> Subject: BS8723 in SKOS (was: Re: Label management
> information in SKOS-XL (continuing from UMTHES and SKOS-XL))
>
> Hi Johan,
>
> I think bs8723.owl it is a valid model and a good starting
> proposal, but
> in some aspects I would follow a different approach. Here I find your
> OWL model too close to the original UML/XSD
> (schemas.bs8723.org), so it
> does not benefit from the enhanced expressive power of OWL.
> Let me give
> four considerations for today:
>
> (1) bs8723:lexicalValue vs. umt:lexicalVariant
>
> One thing our models have in common (or at least very
> similar) is adding
> lexical properties to xl:Label.
> I am talking about bs8723:lexicalValue and
> umtthes:lexicalVariant. Both
> are data properties, not Label relations, and the lexical value (or
> variant) itself is not a xl:Label instance, but a simple Literal.
>
> Antoine has argued against this in
> http://lists.w3.org/Archives/Public/public-esw-thes/2009Oct/0012.html:
> "not attaching that string to an instance of xl:Label using
> xl:literalForm prevents you from benefitting from the useful property
> chains given in XL. So I would have represented 'wastewater' as an
> instance of xl:Label."
> Just like the (non-normative) label relation examples in the primer.
>
> I responded that I would not want a property chain for lexicalVariant,
> as these are meant to be properties of the Label, not of the related
> Concept. This might be arguable, but I see that your bs8723 goes the
> same way.
>
> However, there is a little difference:
>
> bs8723:lexicalValue is subProperty of xl:literalForm.
> umtthes:lexicalVariant is subProperty of rdfs:Label.
>
> What makes the difference?
> Unlike skos:preLabel etc., xl:literalForm is not a subproperty of
> rdfs:Label itself.
> When someone searches all the rdfs:label incl. subproperties in your
> model, this will not include the bs8723:lexicalValue instances.
> This finally depends on your intentions.
>

JDS: start:

1) xl:Label must be able to get other literal properties.
On the EUROVOC project, I used permutedLiteralForm.
Basically the Thesaurus management system was set-up not to have such
permuted literals as resources (e.g. of a controlled vocabulary - that would
make things more complex).
However when mapping to SKOS, the application would make the
permutedLiteralForm a skos:hiddenLabel
(without there being any xl:hiddenLabel), using a dedicated rule (chain)
[I think this is much in line with your lexicalVariant.]

2) I would not use bs:lexicalForm any more if I were to redo the schema.  
It has no additional value over xl:literalForm

3) The bs:literalForm would be found as an rdfs:label because
- bs:literalForm entails xl:literalForm
- ( xl:***Label; xl:literalForm ) entails skos:***literalForm
- skos:***literalForm entails rdfs:label

JDS: end:

>
> (2) ISO to skos or skos to ISO
>
> Whenever mapping between two standards, one can see this from
> two sides:
> looking from ISO to skos, or from skos to ISO.
>
> I think you model is looking from ISO to skos, while mine is looking
> from skos to ISO.
> May be this is even more about looking from UML/XSD to RDF/OWL or vice
> versa.

JDS: yes

>
> The original BS8723 model (schemas.bs8723.org) is expressed
> in UML/XSD.
> This is why there are so many "association classes". In
> RDFS/OWL I would
> use rdfs:subPropertyOf instead. One example:
>
> # Following bs8723.owl
>
> <mammal> rdf:type bs:ThesaurusConcept .
> <cat> rdf:type bs:ThesaurusConcept .
>
> [] rdf:type bs:HierarchicalRelationship ;
>     bs:hasBroaderConcept <mammal> ;
>     bs:hasNarrowerConcept <cat> ;
>     bs:hierarchyType <YourType> .
>
> # end of example 1
>
> Why don't you use skos:broader und skos:narrower?
> I guess this is only due to the UML pattern of encoding
> something like a
> sub-property by providing a "hierarchyType" property in an Association
> Class. Looking at the http://schemas.bs8723.org examples, they use
> "NT", "BT", "BT/BTI", "NT/NTP"  etc. for generic, partitive
> and instance
> hierarchies as hierarchy types.
>
> # In SKOS I would say:
>
> ext:broaderYourType rdfs:subPropertyOf skos:broader;
> ext:narrowerYourType rdfs:subPropertyOf skos:narrower;
>
> <mammal> rdf:type skos:Concept;
>     ext:narrowerYourType <cat>.
> <cat> rdf:type skos:Concept;
>     ext:broaderYourType <mammal>.
>
> # end of example 2
>
> The same applies to:
> bs8723:AssociativeRelationShip
> bs8723:CompoundEquivalence
> bs8723:EquivalenceRelationship
>

JDS: start:

1) In very rare cases, using an association class may be required by the
business.
Your proposal works in nearly all examples I have seen.
The exception I came across was when I was studying Polish legislation
taxonomies.
These had an applicability period (start- and end-date) on associations.  It
would not be possible to add a period on a property.

2) Example 2 (above) gives a better semantic modelling.
Semantics are much more explicit in a property definition than in a 'type'
property on an association class.
Note: Using a hierarchy of association classes would give equivalent
semantic explicitness to the association class approach.

3) Association classes can be mapped to more SKOS compliant artifacts
When representing association classes is SKOS, the SKOS-XL pattern can be
re-used:
- making xl:***Label o xl:literalForm is-a subPropertyOf skos:***Label
Likewise:
- making inverseOf(bs:hasBroaderConcept) o bs:hasNarrowerConcept is-a
subPropertyOf skos:narrower
  (with a SPARQL "construct" this could be refined based on the association
type)

JDS: end:

>
> (3) Do we need bs8723:ThesaurusConcept as a subclass of skos:Concept?
>
> You see in my last example I silently dropped bs:ThesaurusConcept and
> used skos:Concept instead.
> bs:ThesaurusConcept is domain of several properties
> (bs8723:preferredTerm, bs8723:nonPreferredTerm, etc.) which are not
> mandatory, so one might use skos:Concept in the domain as
> well, or even
> rdf:Resource like skos(xl):prefLabel etc. .
>
> Do you really want to say: Anything having a bs:preferredTerm is a
> bs:ThesaurusConcept?
> (remember discussion about "Using DBpedia resources as
> skos:Concepts").
>
> Looks like your bs8723 OWL tries to express closed world constraints
> just like UML/XSD does.
>
> Why not donate bs:preferredTerm as a property to the open world
> (including skos:Concept)?
>
> In this case you would not need a specialized bs:ThesaurusConcept.
>
> The same applies to:
> bs8723:Note
>

JDS: start:

I may be missing some open world practice here but let me explain the line
of thought I had.
>From a thesaurus management point of view, a controlled vocabulary is
managed with the thesaurus.
An in that (closed) world (unlike folksonomy), what comes in the vocabulary
is controlled and
the concepts labeled by those vocabulary terms are managed.

Bottom line:
Can we use open world technology to represent closed world managed systems;
Or shall these closed world systems become open systems ?
It is usually a hard selling point to say to a publisher he is not the one
managing his KOS any more.  He may be doing this is  a co-operative way with
trusted partners/clients, but not with the "Anybody" of the open world AAA.

JDS: end:

>
> (4)  pref / nonPref specialisation of xl:Label
>
> This is in some parts similar to what I have proposed : making a Term
> pref or nonPref on its own.
> Here I don't really understand the
> bs8723:CompoundNonPreferredTerm pattern.
> Even a PreferredTerm may be compound.

JDS: start:

1) Concept decomposition
True, but the decomposition of the PT (as being the label of a concept), is
not needed.
Such a concept decomposition could be managed differently (e.g. by a poly
hierarchy).
For compound nPT (not representing a unique concept) there is a need to list
the component PT (being representatives of a concept).

2) Linguistic decomposition
There is a more SKOS-XL compliant modelling possible, we could define:
- on an xl:Label of type bs:CompoundNonPreferredTerm
  2 or more bs:preferredTermComponent properties (from compound-non-PT to
PT)
- the inverse of a bs:preferredTermComponent is a
bs:compoundNonPreferredTerm
In this modelling, each compound-non-PT can have only one decomposition.
In ISO [an association class approach], multiple decompositions are
possible.
(I think your presentation handled multiple decompositions in a different
way.
Thereby providing decomposition on PT as well as on non-PT.
Therefore I thought this was about linguistic decomposition, not about
concept decomposition.)

JDS: end:

>
> But I guess this is more about coordination.
> http://schemas.bs8723.org/ExampleCompounds/Example.xml has an
> XML example:
>
> <CompoundNonPreferredTerm dc:identifier="3">
> <LexicalValue>austenitic chromium manganese steel</LexicalValue>
> <dcterms:created>2007-05-24</dcterms:created>
> <USE Role="USE +">5</USE>
> <USE Role="USE +">6</USE>
> <USE Role="USE +">7</USE>
> </CompoundNonPreferredTerm>
>
> What if I want "austenitic chromium manganese steel"  to be a
> PreferredTerm and then describe the composition?
>
>
> After all, i think such discussion would benefit from
> thesaurus instance
> examples.
>
> Kind regards,
> Thomas
>
>
> > Hi Thomas,
> >  
> > As stated,
> > - the exercise dates back from end 2008
> >   (I did update the imports as the SKOS core namespace
> issue was still
> > 2008/05).
> > - I made it when reviewing the help my understanding in
> mapping it to SKOS
> > - It was never discussed publicly and needs corrections
> > - It has not been aligned with the recent ISO DIS that was
> circulated.
> >  
> > If it is useful, it can be the start of the exercise
> suggested by Thomas.
> >  
> > Johan.
> >
> >
> --------------------------------------------------------------
> ----------
> > *From:* public-esw-thes-request@...
> > [mailto:public-esw-thes-request@...] *On Behalf Of
> *Thomas Bandholtz
> > *Sent:* Thursday, 05 November, 2009 09:32
> > *To:* SKOS
> > *Subject:* RE: Label management information in SKOS-XL (continuing
> > from UMTHES and SKOS-XL)
> >
> > Hi Christophe, Johan, Leonard, and others,
> >
> > "SKOS / ISO 25964 interchangeability" should be seen as a strategic
> > target, as long as this will not *restrict* any future SKOS usage to
> > the ISO patterns.
> >
> > I really like Christophe's wording:
> >
> > [Christophe:]
> > > There is a rather striking difference between SKOS flexibility and
> > extendability
> > > (opening ways to unstandardized horizons) and ISO willingness
> > > to build upon the past within a stricter frame.
> >
> > So, let us leave SKOS as flexible as it is, but let us try to
> > harmonize some recommended SKOS extension for ISO interoperability.
> >
> > Johan obviously has drafted something like that some tome ago:
> >
> > [Johan:]
> > > JDS-3: on an earlier version of SKOS-XL, I made an exercise some
> > time ago to cover the BS8723
> > > (which was input for the ISO standard)
> > > JDS-3: note this exercise was never discussed on any forum yet
> >
> > Johan, have you made this exercise public? It might be a
> good starting
> > point.
> >
> >
> > I would like to contribute some of my own considerations about Label
> > management here.
> >
> > Coordination should be handled in a different thread, as (following
> > Leonard in this regard) coordination might rather be about Concepts,
> > not Labels.
> >
> > [Leonard:]
> > > Coordination of concepts has previously been discussed during the
> > development of SKOS
> > > but was not followed through because it was "too hard" to
> deal with
> > within the time available, ...
> >
> > Christophe may see this differently, but I will focus on some basic
> > Label / Term patterns in the following.
> >
> > Christophe has started this thread with one concise example:
> >
> > [Christophe:]
> > > Looking at ISO 25964, I have:
> > > Attributes of ThesaurusTerm:
> > > LexicalValue String      1 The wording of the term
> > > identifier   String      1 A unique identifier for the term
> > > created      date     0..1 The date when the term was created
> > > modified     date     0..1 The date when the term was
> last modified
> > > source       String   0..1 The person(s) or document(s) from which
> > the term was taken
> > > Status       String   0..1 Indication of whether the term is
> > candidate, approved, etc.
> > > lang         language 0..1 A code showing the language of
> the term.
> > This should be
> >                            included if the thesaurus supports more
> > than one language
> >
> > To me this looks rather simple. These attributes may be
> mapped as follows:
> >
> > iso:lexicalValue -> skosxl:literalForm
> > iso:identifier: -> URI of the Label resource
> > iso:created, modified, source -> dct:created, etc.
> > iso:status -> might be expressed as a skos:editorialNote
> > iso:lang -> RDF language tag attached to the literalForm.
> >
> > Some of these mapping may be arguable, but I connot find any
> > structural challenge in this example.
> >
> > Looking at the ISO model provided by Leonard (thanks
> Leonard for this
> > update!) as well as to the patterns of UMTHES, I find the
> most crucial
> > difference between SKOS and ISO is about distinguishing preferred
> > terms from-non preferred terms.
> >
> > SKOS distinguishes xl:prefLabel from xl:altLabel relations, but the
> > related xl:Label itself is unclassified in this regard.
> >  
> > Following the SKOS(XL) semantics, one and the same xl:Label
> may appear
> > as prefLabel of one Concept and as altLabel of another.
> >
> > SKOS only keeps you from using the same Label as pref and alt in the
> > same Concept:
> >
> > > SKOS S13: "skos:prefLabel, skos:altLabel and skos:hiddenLabel are
> > pairwise disjoint properties."
> >
> > This make only one usage pattern unvalid:
> >
> > # one concept with the same label as pref/alt
> > # not valid due to S13
> >
> > <Love> skosxl:prefLabel <love> ;
> >     skosxl:altLabel <love> .
> >
> > But the following should be compliant with the explicit SKOS
> > semantics, as far as I see:
> >
> > # two concepts with reverse pref/alt Labels
> > # valid in SKOS but unwanted by ISO
> >
> > <A> skosxl:prefLabel <love>;
> >     skosxl:altLabel <adoration> .
> >
> > <B> skosxl:prefLabel <adoration> ;
> >     skosxl:altLabel <love> .
> >
> >
> > SKOS pref/alt of a label only exists in the context of a given
> > Concept, while ISO pref/nonPref is bound to a given label (~term).
> >
> > Further more, SKOS(XL) does not contain any equivalence
> relation. One
> > might see something similar when looking at a single Concept: the
> > prefLabel of this Concept may be seen as equivalent to the
> altLabel of
> > the same Concept.
> >
> > But again, this is not a relation between the two Labels,
> it is just a
> > usage pattern in the context of a single Concept, and the same two
> > Labels may be used differently in the context of another Concept.
> >
> > If we want to have something like ISO term specialization &
> > equivalence in a SKOS extension I would draft this as follows:
> >
> > First, define ext:prefTerm and ext:nonPrefTerm both as subclasses of
> > skosxl:Label.
> >
> > ext:prefTerm rdfs:subClassOf skosxl:Label .
> > ext:nonPrefTerm rdfs:subClassOf skosxl:Label .
> >
> > Now make these two classes disjoint.
> >
> > ext:prefTerm owl:disjointWith nonPrefTerm .
> >
> > Declare a subProperty of skosxl:prefLabel with ext:prefTerm in its
> > range (btw. this should be valid in OWL2).
> >
> > ext:hasPrefTerm rdfs:subProperty skosxl:prefLabel;
> >     rdfs:range ext:prefTerm .
> >
> > Declare another subProperty of skosxl:altLabel with
> ext:nonPrefTerm in
> > its range.
> >
> > ext:hasNonPrefTerm rdfs:subProperty skosxl:altLabel;
> >     rdfs:range ext:nonPrefTerm .
> >
> > Now define use/usedFor both as subProperties of
> skosxl:labelRelation.
> >
> > ext:usedFor rdfs:subPropertyOf skosxl:labelRelation;
> >     rdfs:domain ext:prefTerm;
> >     rdfs:range ext:nonPrefTerm;
> >     owl:inverseOf ext:use .
> >
> > Now you can write:
> >
> > <love> ext:usedFor <adoration> .
> >
> > From this will be inferred:
> >
> > <love> rdf:type ext:prefTerm .
> > <adoration> rdf:type ext nonPrefTerm .
> >
> > and
> >
> > <adoration> ext:use <love> .
> >
> > Note that all this leaves the existing SKOS semantics untouched, but
> > it provides an extension with more strict semantics:
> >
> > # not valid:
> > <A> ext:prefTerm <love>;
> >     ext:nonPrefTerm <adoration> .
> >
> > <B> ext:prefTerm <adoration> ;
> >     ext:nonPrefTerm <love> .
> >
> > As far as I see, this proposal conforms to the existing SKOS
> > recommendation and (basically) allows expressing some more
> strict ISO
> > patterns.
> >
> > I would like to discuss and clarify this so far before moving on to
> > the more complex "compound" and "split" patterns.
> >
> > What do you think?
> >
> > Kind regards,
> > Thomas
> > --
> > Thomas Bandholtz, thomas.bandholtz@..., http://www.innoq.com 
> > innoQ Deutschland GmbH, Halskestr. 17, D-40880 Ratingen, Germany
> > Phone: [phone] Mobile: [phone] Fax: [phone]
> >  
>
>
>

[Antoine Isaac-2]

Hi everyone,

I think it would be a very good idea to have this ISO/SKOS alignment/extension work done!
Even though I might have not much time these days to push it, unfortunately :-/

As a matter of fact, the pattern and axioms proposed by Thomas for pref and alt labels seem very sensible to me.

I'd just like to emphasize that introducing specific PrefTerm/NonPrefTerm and explicitly representing equivalence links at their level it does not correspond to a strict requirement in SKOS.
As Thomas said, this can perfectly be derived from the prefLabel/altLabel statements with instances of xl:Label as objects, so there is redundancy. So no one using SKOS-XL should feel forced to use PrefTerm/NonPrefTerm classes and their associated machinery, if the only goal is to be compliant with SKOS-XL (this comments is especially aimed at Thomas, who was wondering about the validity of using that in his conversion of UMTHES).
But of course it does help materializing the alignment to ISO, so it is very much ok to use it, for those who are interested in that point.
(and even then, as far as I can understand Leonard's graph, the UF/USE relations are also redundant in ISO with the use of the isNonPreferredLabelFor/isPreferredLabelFor ones; but I won't discuss that here, and just assume that we should aim at mapping all relevant features in ISO)

A couple of minor (picky) comments:
- usual notations for classes and properties start with upper-case, so I'd expect, e.g, ext:PrefTerm and ext:NonPrefTerm instead of ext:prefTerm and ext:nonPrefTerm
- for a mapping to ISO, I'd recommend to stick to the ISO choice for labels (for classes or properties) rather than adhoc ones, whenever possible. So, ext:PreferredTerm instead of ext:PrefTerm, and so on. That's really a detail, but that can help future communication with ISO people...

Cheers,

Antoine

> Hi Thomas,
>  
> As stated,
> - the exercise dates back from end 2008
>   (I did update the imports as the SKOS core namespace issue was still
> 2008/05).
> - I made it when reviewing the help my understanding in mapping it to SKOS
> - It was never discussed publicly and needs corrections
> - It has not been aligned with the recent ISO DIS that was circulated.
>  
> If it is useful, it can be the start of the exercise suggested by Thomas.
>  
> Johan.
>
> ------------------------------------------------------------------------
> *From:* public-esw-thes-request@...
> [mailto:public-esw-thes-request@...] *On Behalf Of *Thomas Bandholtz
> *Sent:* Thursday, 05 November, 2009 09:32
> *To:* SKOS
> *Subject:* RE: Label management information in SKOS-XL (continuing from
> UMTHES and SKOS-XL)
>
> Hi Christophe, Johan, Leonard, and others,
>
> "SKOS / ISO 25964 interchangeability" should be seen as a strategic
> target, as long as this will not *restrict* any future SKOS usage to the
> ISO patterns.
>
> I really like Christophe's wording:
>
> [Christophe:]
>  > There is a rather striking difference between SKOS flexibility and
> extendability
>  > (opening ways to unstandardized horizons) and ISO willingness
>  > to build upon the past within a stricter frame.
>
> So, let us leave SKOS as flexible as it is, but let us try to harmonize
> some recommended SKOS extension for ISO interoperability.
>
> Johan obviously has drafted something like that some tome ago:
>
> [Johan:]
>  > JDS-3: on an earlier version of SKOS-XL, I made an exercise some time
> ago to cover the BS8723
>  > (which was input for the ISO standard)
>  > JDS-3: note this exercise was never discussed on any forum yet
>
> Johan, have you made this exercise public? It might be a good starting
> point.
>
>
> I would like to contribute some of my own considerations about Label
> management here.
>
> Coordination should be handled in a different thread, as (following
> Leonard in this regard) coordination might rather be about Concepts, not
> Labels.
>
> [Leonard:]
>  > Coordination of concepts has previously been discussed during the
> development of SKOS
>  > but was not followed through because it was "too hard" to deal with
> within the time available, ...
>
> Christophe may see this differently, but I will focus on some basic
> Label / Term patterns in the following.
>
> Christophe has started this thread with one concise example:
>
> [Christophe:]
>  > Looking at ISO 25964, I have:
>  > Attributes of ThesaurusTerm:
>  > LexicalValue String      1 The wording of the term
>  > identifier   String      1 A unique identifier for the term
>  > created      date     0..1 The date when the term was created
>  > modified     date     0..1 The date when the term was last modified
>  > source       String   0..1 The person(s) or document(s) from which
> the term was taken
>  > Status       String   0..1 Indication of whether the term is
> candidate, approved, etc.
>  > lang         language 0..1 A code showing the language of the term.
> This should be
>                            included if the thesaurus supports more than
> one language
>
> To me this looks rather simple. These attributes may be mapped as follows:
>
> iso:lexicalValue -> skosxl:literalForm
> iso:identifier: -> URI of the Label resource
> iso:created, modified, source -> dct:created, etc.
> iso:status -> might be expressed as a skos:editorialNote
> iso:lang -> RDF language tag attached to the literalForm.
>
> Some of these mapping may be arguable, but I connot find any structural
> challenge in this example.
>
> Looking at the ISO model provided by Leonard (thanks Leonard for this
> update!) as well as to the patterns of UMTHES, I find the most crucial
> difference between SKOS and ISO is about distinguishing preferred terms
> from-non preferred terms.
>
> SKOS distinguishes xl:prefLabel from xl:altLabel relations, but the
> related xl:Label itself is unclassified in this regard.
>  
> Following the SKOS(XL) semantics, one and the same xl:Label may appear
> as prefLabel of one Concept and as altLabel of another.
>
> SKOS only keeps you from using the same Label as pref and alt in the
> same Concept:
>
>  > SKOS S13: "skos:prefLabel, skos:altLabel and skos:hiddenLabel are
> pairwise disjoint properties."
>
> This make only one usage pattern unvalid:
>
> # one concept with the same label as pref/alt
> # not valid due to S13
>
> <Love> skosxl:prefLabel <love> ;
>     skosxl:altLabel <love> .
>
> But the following should be compliant with the explicit SKOS semantics,
> as far as I see:
>
> # two concepts with reverse pref/alt Labels
> # valid in SKOS but unwanted by ISO
>
> <A> skosxl:prefLabel <love>;
>     skosxl:altLabel <adoration> .
>
> <B> skosxl:prefLabel <adoration> ;
>     skosxl:altLabel <love> .
>
>
> SKOS pref/alt of a label only exists in the context of a given Concept,
> while ISO pref/nonPref is bound to a given label (~term).
>
> Further more, SKOS(XL) does not contain any equivalence relation. One
> might see something similar when looking at a single Concept: the
> prefLabel of this Concept may be seen as equivalent to the altLabel of
> the same Concept.
>
> But again, this is not a relation between the two Labels, it is just a
> usage pattern in the context of a single Concept, and the same two
> Labels may be used differently in the context of another Concept.
>
> If we want to have something like ISO term specialization & equivalence
> in a SKOS extension I would draft this as follows:
>
> First, define ext:prefTerm and ext:nonPrefTerm both as subclasses of
> skosxl:Label.
>
> ext:prefTerm rdfs:subClassOf skosxl:Label .
> ext:nonPrefTerm rdfs:subClassOf skosxl:Label .
>
> Now make these two classes disjoint.
>
> ext:prefTerm owl:disjointWith nonPrefTerm .
>
> Declare a subProperty of skosxl:prefLabel with ext:prefTerm in its range
> (btw. this should be valid in OWL2).
>
> ext:hasPrefTerm rdfs:subProperty skosxl:prefLabel;
>     rdfs:range ext:prefTerm .
>
> Declare another subProperty of skosxl:altLabel with ext:nonPrefTerm in
> its range.
>
> ext:hasNonPrefTerm rdfs:subProperty skosxl:altLabel;
>     rdfs:range ext:nonPrefTerm .
>
> Now define use/usedFor both as subProperties of skosxl:labelRelation.
>
> ext:usedFor rdfs:subPropertyOf skosxl:labelRelation;
>     rdfs:domain ext:prefTerm;
>     rdfs:range ext:nonPrefTerm;
>     owl:inverseOf ext:use .
>
> Now you can write:
>
> <love> ext:usedFor <adoration> .
>
>  From this will be inferred:
>
> <love> rdf:type ext:prefTerm .
> <adoration> rdf:type ext nonPrefTerm .
>
> and
>
> <adoration> ext:use <love> .
>
> Note that all this leaves the existing SKOS semantics untouched, but it
> provides an extension with more strict semantics:
>
> # not valid:
> <A> ext:prefTerm <love>;
>     ext:nonPrefTerm <adoration> .
>
> <B> skosxl:prefLabel <adoration> ;
>     skosxl:altLabel <love> .
>
> As far as I see, this proposal conforms to the existing SKOS
> recommendation and (basically) allows expressing some more strict ISO
> patterns.
>
> I would like to discuss and clarify this so far before moving on to the
> more complex "compound" and "split" patterns.
>
> What do you think?
>
> Kind regards,
> Thomas
>
> --
> Thomas Bandholtz, thomas.bandholtz@..., http://www.innoq.com 
> innoQ Deutschland GmbH, Halskestr. 17, D-40880 Ratingen, Germany
> Phone: [phone] Mobile: [phone] Fax: [phone]

[Stella Dextre Clarke-2]

Antoine Isaac wrote:
> Hi everyone,
>
> I think it would be a very good idea to have this ISO/SKOS
> alignment/extension work done!
I'm taking "ISO" to be shorthand for "ISO 25964", and speaking as the
leader of the project to develop this standard, would like to assure the
SKOS community that we too are very happy to see better alignment. ("We"
means "WG8" which is the short name for the working group
ISO/TC46/SC9/WG8 which is responsible for the work.) As a first step, we
wish we could circulate our working documents and get your comments.
Unfortunately, however, ISO copyright rules prevent us doing so.  The
high price of ISO standards is another cause of much grief. But the
(relatively) good news is that drafts cost a lot less than the eventual
standards. And we've had a promise from BSI that they will very soon
make a copy of our latest draft available for online viewing and
commenting (without charge). I will post another message when it is
released.

The prospects for better alignment seem good, since there has already
been quite a bit of communication between our communities, dating back
to the development period of the precursor standard BS8723, alongside
earlier versions of SKOS. As I see it, we share a lot of common
objectives, although we are addressing slightly different "links" in the
"chain" of  standards needed to make KOSs work effectively. In WG8 we
are mostly concerned with how to construct thesauri, whereas SKOS  deals
with how to publish them on the Web. Both of us  are keen to promote
interoperability, and so there is an overlap of shared interests.

Despite the shared interests and objectives, very few  WG8 members have
expertise in RDF, OWL, etc and so we often find it difficult to
contribute directly to the SKOS discussions. However, please do not
interpret silence as lack of goodwill! We do sincerely want to support
your efforts towards interoperability between KOSs.

I'll be in touch again soon.
Stella
*****************************************************
Stella Dextre Clarke
Information Consultant
Luke House, West Hendred, Wantage, OX12 8RR, UK
Tel: [phone]
Fax: [phone]
stella@...
*****************************************************