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

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@innoq.com] 
> 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@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 23:57:13 UTC