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.


(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@w3.org
> [mailto:public-esw-thes-request@w3.org] *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@innoq.com, http://www.innoq.com 
> innoQ Deutschland GmbH, Halskestr. 17, D-40880 Ratingen, Germany
> Phone: +49 228 9288490 Mobile: +49 178 4049387 Fax: +49 228 9288491
>

Received on Sunday, 8 November 2009 18:31:34 UTC