- From: Johan De Smedt <johan.de-smedt@tenforce.com>
- Date: Sun, 25 Oct 2009 21:28:11 +0100
- To: "'Thomas Bandholtz'" <thomas.bandholtz@innoq.com>
- Cc: "'SKOS'" <public-esw-thes@w3.org>, "'Antoine Isaac'" <aisaac@few.vu.nl>
- Message-ID: <DA24681D2AA446C39E37517D6A21772A@TFJOHAN>
Hi Thomas, Please find in-line and prefixed with ">>JDS-2:" clarifications on your added questions. In the examples, "ev:" stands for the EUROVOC schema prefix. kr, Johan De Smedt. =================== _____ From: Thomas Bandholtz [mailto:thomas.bandholtz@innoq.com] Sent: Sunday, 25 October, 2009 20:13 To: Johan De Smedt Cc: 'SKOS'; 'Antoine Isaac' Subject: Re: UMTHES and SKOS-XL Hi Johan, some considerations inline: [skip] I see SKOS primarily as an exchange format not as a maintenance format. This is a very important issue. I used to see SKOS purely as an exchange format either, but since LOD I understand skosified reference vocabularies as an important building block at runtime. This does not constrain maintenance to anything else than the vocabulary has to be serializable in SKOS so that it will meet the expectations of a SKOS aware application. Users of the EUROVOC thesaurus maintenance system manage permuted literals as properties of preferred or alternate xl:Labels. Hence: - the genuine managed labels are ok to have a URI that can later be used in an LOD or SPARQL service interface - permuted literal forms do not have this quality However, when making a SKOS compliant publication, the hidden label has relevance (as search value) Hence EUROVOC publishes for a skos:Concept :C - :C xl:prefLabel :ptC; xl:altLabel :nptC; skos:hiddenLabel "permuted literal form of C" . - :ptC xl:literalForm "PT of C" . - :nptC xl:literalForm "nPT of C" . I think this is compliant with SKOS(XL) - comment is welcome. I don't see any reason why this should not be compliant with SKOS. But it may not express your semantics: >>JDS-2: indeed, not all semantics are expressed that is what I try to explain below.. You provide prefLabel and altLabel with XL, but hiddenLabel in plain SKOS, so how will you express that some permuted literal form refers to one of the labels? A Concept by itself has no literal form, so i do not understand how it may have a permuted literal form. Is there exactly one permuted literal form per Concept or per Label? Could you give an example? >>JDS-2: example: C stands for the concept with preferred term "child abuse" :C xl:prefLabel :childAbuse :childAbuse xl:literalForm "child <mailto:> abuse"@en . :childAbuse ev:permutedLiteralForm "abuse, <mailto:> child"@en . For this, the EUROVOC publishing service generating SKOS will generate in addition :C skos:prefLabel "child abuse"@en <mailto:> . :C skos:hiddenLabel "abuse, child"@en <mailto:> . This is based on the following two (informally noted) rules that go with the EUROVOC schema - A chain xl:prefLabel([Concept][Term]) o ev:permutedLiteralForm([Term][literal]) → skos:hiddenLabel([Concept][literal]) . - A chain xl:altLabel([Concept][Term]) o ev:permutedLiteralForm([Term][literal]) → skos:hiddenLabel([Concept][literal]) . The details of why - :nptC is an an alt label - "permuted literal form of C" is a permuted label can be found in the equivalence relationships (simple or compound) or in the permuted literal forms of either :ptC or :nptC. This is expressed in the EUROVOC specific SKOS extension (and thus requires knowledge of the owl schema beyond the formal OWL expressions - i.e. the documentation that goes with the schema). I understand that "ptC" stands for "preferred term of a Concept" and "nptC" for "non-preferred term of a Concept", right? >>JDS-2: yes. The basic ISO equivalence relationship is "preferredTerm USED FOR non-preferredTerm" with inverse "non-preferredTerm USE preferredTerm". There is no such construct in SKOS. A SKOSXL Label cannot be preferred or not by itself, it only depends on how it is linked to a Concept (pref/altLabel). (see an example below ...) Guess that is the reason why you have a EUROVOC specific SKOS extension (which we don't know so far). I wonder how you express "permuted literal forms of either :ptC or :nptC", when the permuted literal form is a rdf:Literal? >>JDS-2: an xl:Label may have an arbitrary number of ev:permutedLiteralForm. This is a data property (like xl:literalForm). >>JDS-2: in contrast though, ev:permutedLiteralForm has no cardinality constraints. >>JDS-2: further, for any xlLabel :L, its property xl:literalForm and all its ev:permutedLiteralForm must have the same language. This might be a special case, but xs:labelRelation is intended to point to a xl:Label instance, not to a Literal. The selection of something being a PT or an nPT or a permuted label is up to the thesaurus maintenance/management. It is not always obvious if either an acronym ("OWL") or the full name ("Web Ontology Language") will be used as PT in a real world thesaurus. (Like considerations apply for other label relations) However, once a name is selected as the PT, the related labels are likely (mandatory?) candidates for nPT or hidden labels. As there currently is no SKOS extension capturing such label relations, we now discuss on which approach to take. I would advocate that for some of the work done on the ISO standardization, it may be worthwhile to do some RDF standardization effort in the future. Possible candidates are: - Concept groups What is the difference from a skos:Collection? >>JDS-2: group means any subset of concepts while collections where aimed to represent "node labels" and "facets". >>JDS-2: I think Stella and Antoine are better placed to respond to this accurately. - Equivalence relationships (simple and compound) SKOS only has altLabel prefLabel relations from a Concept to a Label. >From this arises the question whether the same Label my be pref of one Concept and alt of another? Would this be compliant? Yes (may be not intentionally). S13: "skos:prefLabel, skos:altLabel and skos:hiddenLabel are pairwise disjoint properties." S14: "A resource has no more than one value of skos:prefLabel per language tag." These only keep you from saying something like: <Love> skos:prefLabel "love"@en ; skos:prefLabel "adoration"@en . or <Love> skos:prefLabel "love"@en ; skos:altLabel "love"@en . But the following is compliant: <A> skos:prefLabel "love"@en ; skos:altLabel "adoration"@en . <b> skos:prefLabel "adoration"@en ; skos:altLabel "love"@en . Or even more evident in XL: <A> skosxl:prefLabel :love; skosxl:altLabel :adoration . <B> skosxl:prefLabel :adoration ; skosxl:altLabel :love . :love skosxl:literalForm "love"@en . :adoration skosxl:literalForm "adoration"@en. SKOS pref/alt of a label is only known in the context of a given Concept, while ISO pref/nonPref is bound to a given label (~term). Right? >>JDS-2: I agree and this makes ISO Thesaurus semantics more strict than SKOS (as you demonstrate in the example below). If you want to have ISO equivalence in SKOS you may express something like: prefTerm subClassOf xl:Label . nonPrefTerm subclassOf xl:Label . prefTerm disjointWith nonPrefTerm . xl:prefLabel range prefTerm . xl:altLabel range nonPrefTerm . >>JDS-2: I do not follow with these last 2 rules as they would redefine SKOS-XL. >>JDS-2: Instead we define ev:EquivalenceRelation relating a prefTerm and a nonPrefTerm using properties ev:use and ev:uf respectively. >>JDS-2: ev:use and ev:uf do have range prefTerm and nonPrefTerm respectively. >>JDS-2: then we say that :C xl:altLabel :nptC is entailed by: >>JDS-2: :C xl:prefLabel :ptC. >>JDS-2: :eqr rdf:type ev:equivalenceRelation ; ev:use :ptC ; ev:uf :nptC. usedFor subPropertyOf xl:labelRelation; domain prefTerm; range nonPrefTerm; inverseOf use . and then: love a prefTerm; adoration a nonPrefTerm; love usedFor adoration. Obviously, the industry may find the schema provided in the ISO standard (UML/XML) sufficient. ? I do not really understand this. >>JDS-2: I mean the ISO standard went a long way: >>JDS-2: The BS preparing it defined an XML schema for Thesauri. >>JDS-2: This covered more than SKOS (this statement is scoped to thesaurus). >>JDS-2: In addition a model was defined using the Unified Modeling Language (UML). >>JDS-2: Likewise this model has more specific thesaurus artifacts. -- 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, 25 October 2009 20:28:55 UTC