W3C home > Mailing lists > Public > public-swd-wg@w3.org > August 2008

RE: SKOS Reference Review Response

From: Sini, Margherita (KCEW) <Margherita.Sini@fao.org>
Date: Tue, 26 Aug 2008 18:05:54 +0200
To: Sean Bechhofer <sean.bechhofer@manchester.ac.uk>
Cc: SWD Working SWD <public-swd-wg@w3.org>
Message-id: <BA453B6B6B217B4D95AF12DBA0BFB669029DB3D0@hqgiex01.fao.org>

Hi there,
 
My comments:
1.1 --> ok fine
1.2 --> ok fine for changes.  New requirements can be put in a list for
future releases maybe?
1.3 --> ok, its more clear for me now.
1.5 --> ok
1.6 --> ok
2   --> ok
3.3 --> ok, its clear now for me like 1.3
3.5.1 --> ok, better
4.2 --> ok
4.6.1 --> ok, got it, but i suggest to keep these (e.g. URI for concepts in
multiple schemes) as open points for further discussions in other releases
(?)
4.6.4 --> ok, but why you do not want to add such constraint in SKOS?
5 --> ok, i see. Point open for the future (?)
6.5.3 --> ok
8.1 --> ok, but clearer relationship names would help.
8.4 --> ok
8.6.7 --> yes sorry my confusion... but why not making it non irreflexive?
are we sure there are uses cases supporting this?
10 --> yes, i think that making chain axioms will be good because personally
i see this as in the normal way people use these relationships...
 
Let's say in general I found that in some cases you decided not to express
something or not too express too much, or not put some restrictions... e.g.
some decisions on not making specific assertions on properties... I wonder
why... Would it be good to have examples that support these decisions?
 
Hope this helps
Margherita

 
 

	-----Original Message----- 
	From: public-swd-wg-request@w3.org on behalf of Sini, Margherita
(KCEW) 
	Sent: Mon 8/25/2008 09:57 
	To: Sean Bechhofer 
	Cc: SWD Working SWD 
	Subject: RE: SKOS Reference Review Response
	
	


	Dear Sean and Alistar,
	
	Thanks for this. I will leave in half and hour to go Hyderabad
south-India,
	where I will have a less reliable internet connection. I have saved
the email
	and the web page on my laptop so i can work on it hopefully tonight.
	I will send you a reply hopefully tomorrow or in 2 days maximum.
	
	Thanks
	Margherita
	
	
	        -----Original Message-----
	        From: Sean Bechhofer [mailto:sean.bechhofer@manchester.ac.uk]
	        Sent: Fri 8/22/2008 11:00
	        To: Sini, Margherita (KCEW)
	        Cc: SWD Working SWD
	        Subject: SKOS Reference Review Response
	       
	       
	
	
	
	        Dear Margherita
	       
	        SKOS Simple Knowledge Organisation Systems Reference Draft 30
July
	2008
	       
	        Thank you for your review of the above document. We have made
a
	number
	        of changes which we believe address the comments that you
have
	        raised. A revised version of the document is available at:
	       
	        http://www.w3.org/2006/07/SWD/SKOS/reference/20080820/
	       
	        Below, please find in-line responses to your review comments
	        identifying either changes made, explanations or rationale
for making
	        no change. Can you please confirm that you are now in
agreement that
	        this document is ready for Last Call?
	       
	              Sean & Alistair
	       
	
------------------------------------------------------------------
	       
	       
	         > 1.1. Background and Motivation:
	       
	         > In the background and motivation, i would suggest to add a
	        sentence that
	        mention that today no real unified or standardized way for
	representing
	        thesaurus exists: there are ISO standards to structure
thesauri (with
	        specific well defined relationships), but no technical way of
	        representing
	        those... Some are just in word files, some printed in hard
copies,
	        some in
	        any custom defined ms access forms... So This is one other
reason why
	we need
	        SKOS (if not alreaqdy covered by last 2 paragraphs).
	       
	        Amended as: "...The important point for SKOS is that, in
addition to
	        their unique features, each of these families shares much in
common,
	        and can often be used in similar ways. However, there is
currently no
	widely deployed standard for representing these knowledge
	        organization systems as data and exchanging them between
computer
	        systems." AJM
	       
	         > 1.2. What is SKOS?
	         >
	         > I would suggest to change <<<Using SKOS, a knowledge
organization
	        system can
	        be expressed as data.>>> with "... as formalized data." or
"... as
	        computer-processable data."
	       
	        Inserted "...machine readable data...". SKB
	       
	         > In the sentence <<<SKOS concepts can be assigned one or
more
	        notations, which
	        are lexical codes used to uniquely identify the concept
within the
	        scope of a
	        given concept scheme (also known as classification codes).>>>
... can
	we
	        mention something that identify that these "codes" (even if i
would
	        prefer to
	        call them differently... such as "specific alphanumeric or
numeric
	        values, or
	        symbols") are or may be  different from codes used to
create/generate
	the
	        URI? why do we need to "uniquely identify the concept within
the
	        scope of a
	        given concept scheme"... is the URI not enough?
	       
	        Amended as: "SKOS concepts can be assigned one or more
	        <strong>notations</strong>,
	        which are lexical codes used to uniquely identify the concept
within
	the
	        scope of a given concept scheme. While URIs are the preferred
means
	of
	        identifying SKOS concepts within computer systems, notations
provide
	a
	        bridge to other systems of identification already in use such
as
	        classification codes used in library catalogues." AJM
	       
	         > I also propose for other future releases of SKOS that the
WG could
	take in
	        consideration the notion of context of validity of concepts
or
	        relationships,
	        maybe later on adding the notion of "extent" or "validity"...
E.g. a
	        concept
	        or term (label) may be valid only in a specific geographical
area or
	        at a
	        given time, and a relationship may be valid for a specific
culture
	        only. ( I
	        can provide examples if needed, but as i said ... this may be
for
	other
	        releases... if the group think is good to adapt this).
	       
	        This is a new requirement and we don't think this can be
addressed in
	the current draft. AJM
	       
	         > 1.3. SKOS, RDF and OWL:
	         >
	         > I think there is an editorial mistake here: <<<by the
logical
	        characteristics
	        of and interdependencies between those classes and
properties>>>. Is
	        it a
	        mistake "of and"?
	       
	        by the logical characteristics of, and interdependencies
between,
	        those classes and properties. SKB
	       
	         > Suggestion: instead of saying <<<<using the "concepts" of
the
	        thesaurus as a
	        starting point for creating classes, properties and
individuals >>>>
	        I would
	        say "using the "elements" of the thesaurus as a starting
point for
	        creating
	        classes, properties and individuals "  or "using the "main
	        descriptors" of
	        the thesaurus as a starting point for creating classes and
	        individuals, the
	        non-descriptors for labels and relationships for properties
".
	       
	        This paragraph has been removed in response to a comment from
Guus.
	AJM
	       
	         > In the sentence <<<The reason for this is that, because a
	        thesaurus or
	        classification scheme has not been developed with formal
semantics in
	mind,
	        but rather as an informal or semi-formal aid to navigation
and
	        information
	        retrieval, expressing a thesaurus hierarchy directly as a set
of
	        ontology
	        classes with subsumption axioms typically leads to a number
of
	        inappropriate
	        or nonsensical conclusions.>>> maybe you can even add an
example in
	        which
	        sometimes in a thesaurus we may have non-descriptors with
refer to a
	        maybe
	        more generic descriptor... The 2 are related by the
USE/UsedFor
	        relationships
	        but may not necessarily synonyms... so sometimes USE/UsedFor
can be
	        converted
	        into an alternative label for a concept, sometimes they can
be
	        converted in
	        actually 2 different concepts.
	       
	        This paragraph has been removed in response to a comment from
Guus.
	AJM
	       
	         > In the next paragraph: <<<Taking this approach, the
"concepts" of
	        a thesaurus
	        or classification scheme are modeled as individuals in the
SKOS data
	        model>>>
	        this means that skos:Concept  is in OWL an individual?
	       
	        No. skos:Concept is an owl:Class. The particular instances of
	        skos:Concept, e.g.
	        ex:Cat or ex:Dog are individuals (with rdf:type
skos:Concept). SKB
	       
	         > In last example, you are basically saying that
representing a
	        thesaurus in
	        SKOS+OWL i may have some thesaurus elements
	        ("concepts") as owl:class and some others as skos:concepts???
	       
	        The example illustrates that owl:Classes and skos:Concepts
may be
	        mixed arbitrarily. There is nothing in the
	        SKOS Recommendation to prevent this.
	       
	         > Last sentence <<<need to appreciate the distinction>>>
means that
	        users do
	        need to do the distinction or it is not mandatory to make the
	        distinction
	        (between skos:Concept and owl:Class)?
	       
	        Ideally, users should be aware of the distinction, as
different
	        inferences may arise, depending on whether skos:Concepts or
	        owl:Classes are defined. If applications are to respect the
	        underlying semantics of the languages (OWL and RDF), then
they would
	        need to make the distinction. It may be that we can make this
	        clearer. SKB
	       
	         > 1.4. Consistency and Integrity: OK
	       
	         > 1.5. Inference, Dependency and the Open-World Assumption
	       
	         > Sentence <<<and for the possibility of then using
thesauri>>>
	        should maybe be
	        "and for the possibility of using thesauri" (editorial
mistake)?
	       
	        "then" removed. SKB
	       
	         > 1.6. How to Read this Document
	       
	         > I am not a native english speaker so some of my comments
may be
	not
	        appropriate... E.g. sentence <<<Integrity Conditions - if
there are
	any
	        integrity conditions, those are given next.>>>  is "next"
here to be
	        interpreted as "in this section"?
	       
	        The integrity conditions are given in the appropriate
context. The
	        word "next" is unnecessary here and possibly confusing, so it
has
	        been removed. SKB
	       
	         > 1.7. Conformance: OK
	         >
	         > Section: 2.
	         >
	         > My comment about the URI would be that i suggest to keep
alive and
	resolvable
	        the old URI for legacy system, but the new URi should be also
	        published so
	        that new systems may show the new changes. It will be up to
the user
	to
	        decide if they want to move to the new uri or not.
	       
	        No response needed. AJM
	       
	         > 3.3. Class & Property Definitions
	         >
	         > <<<skos:Concept is an instance of owl:Class>>>.   Means
that
	        skos:Concept its
	        an Individual in OWL? I was actually thinking that
skos:Concept is an
	        owl:Class...
	       
	        You are right in your thinking. skos:Concept is an owl:Class.
This is
	exactly what the
	        text says. Recall that owl:Class is a "meta-class", in that
instances
	of owl:Class
	        are classes. SKB
	       
	         > 3.5.1. SKOS Concepts, OWL Classes and OWL Properties
	        You say <<<This specification does not make any statement
about the
	        formal
	        relationship between the class of SKOS concepts and the class
of OWL
	        classes>>> But in section 3.3. Class & Property Definitions
you just
	        said
	        "skos:Concept is an instance of owl:Class"... so how could
you not
	make
	        statement about their relationship if you say one is an
instance of
	the
	        other.... It is not a contracdition?
	       
	        The statement here is intended to highlight the fact that
there is no
	expectation
	        or requirement for a particular skos:Concept to be
interpreted as an
	        owl:Class or to have
	        an associated owl:Class. This has been made clearer through
the
	        following text
	       
	        Other than the assertion that <code>skos:Concept</code> is an
	        instance of <code>owl:Class</code>,
	        this specification does <strong>not</strong> make any
additional
	        statement about the
	        formal relationship between the class of SKOS concepts and
the class
	        of OWL
	        classes. SKB
	       
	         > From the examples and the text i understood that you do
not want
	        to specify
	        if skos:Concept is a class or an individual or any other
element
	(e.g.
	        ObjectProperty)... But then why have you said that
<<<skos:Concept is
	an
	        instance of owl:Class>>>?
	       
	        See above. AJM.
	       
	         > Personally I can see that from a KOS we may have
skos:Concept as
	        owl:Class
	        (e.g. "cows" its a class). Or we may have instances (e.g.
"Batissa
	        violacea",
	        its a specific species of a mollusc).
	       
	        skos:Concept is the class of SKOS concepts, thus is defined
as an
	        instance of
	        owl:Class. Sections 1.2 and 1.3 are intended to explain this.
SKB
	       
	         > 4.2. Vocabulary
	       
	         > Why the <<skos:topConceptInScheme>> has been introduced?
the
	        "skos:hasTopConcept" is enough to be able to represent in any
system
	        the top
	        level elements of a scheme... Do we really have to use
	        <<skos:topConceptInScheme>>? If i generate my skos file this
new
	        statement
	        will make my file bigger without introducing really a new
	        information. In
	        fact I can infere this from the "skos:hasTopConcept"...
	       
	        skos:topConceptInScheme was introduced in order to address
ISSUE 83
	        and to
	        allow the statement of the relationship between skos:inScheme
and
	        skos:hasTopConcept
	        (without resorting to the use of an anonymous property which
is known
	to be
	        problematic). There is no need to assert
skos:topConceptInScheme for
	        any concept
	        that is the subject of a skos:hasTopConcept assertion. The
fact that
	        the two properties
	        are inverses will allow such an inference to be made. SKB
	       
	         > 4.6.1. Closed vs. Open Systems
	         >
	         > I may have a problem with this <<<<MyConcept> takes part
in two
	        different
	        concept schemes>>>... in fact this its true.... BUT.... if we
go to
	the
	        labels level... we may have to keep in kind that the same
concept may
	be
	        lexicalized differently in different schemes... How this will
be
	        represented
	        in SKOS? there is no way yet (maybe?) to express that the
labels
	        attached to
	        an skos:Concept may be from different schemes....
	       
	        This is, in principle, already possible using SKOS XL,
because an
	        instance of xl:Label can have a skos:inScheme property.
However a
	        discussion of design patterns such as this is beyond the
scope of the
	SKOS Reference, and probably needs further exploration within the
	        community of practice. AJM
	       
	         > And what about the URI of
	        the skos:Concept? will it be the one from one scheme (e.g.
	<skos:Concept
	        rdf:about="http://www.fao.org/aims/aos/agrovoc#c_1939">) or
from the
	        other
	        scheme (e.g. <skos:Concept
	        rdf:about="http://agclass.nal.usda.gov/nalt#cows">)?
	       
	        There are a number of possible design patterns here, however
a
	        discussion of these design patterns is beyond the scope of
the SKOS
	        Reference, and probably needs further exploration within the
	        community of practice. AJM
	       
	         > <<<This flexibility is desirable because it allows, for
example,
	        new concept
	        schemes to be described by linking two or more existing
concept
	schemes
	        together.>>> but if it is so.... why there are the mapping
elements
	        exactMatch, narrowMatch, etc... which can be used to link two
or more
	        existing concept schemes? This second solution infact, would
resolve
	the
	        problem of keeping the 2 distinc URi, be able to lexicalized
	differently
	        concepts, but expressing that a concept may take part on 2
different
	        schemes.
	       
	        There are a number of possible design patterns for working
with
	        multiple concept schemes in SKOS, and these need further
	        investigation. Many of these design patterns remain to be
explored or
	well documented, therefore we feel a discussion of these issues is
	        beyond the scope of the SKOS Reference (but would make a
great
	        subject for a follow-up note). AJM
	       
	         > 4.6.4. Top Concepts and Semantic Relations
	         >
	         > How the example is consistent? as we are probably sure
that
	        skos:hasTopConcept will be used for top concept which do not
have any
	BT...
	        should we instead enforce this to be correct in SKOS? i mean
enforce
	        that a
	        top Concept cannot have BT....
	       
	        The example is intended to highlight precisely the fact that
the
	        constraint that you
	        mention (top concept cannot have BT) is 'not' explicitly
represented
	in
	        the SKOS data model and thus there is no inconsistency in the
	        example. SKB
	       
	        We felt it was adequate to handle this situation by a usage
	        convention, which applications can check if they need to,
rather than
	add a formal constraint in the data model. AJM
	       
	        5. Lexical Labels
	       
	         > I am still convinced that in future version of SKOS we do
not need
	"A
	        resource has no more than one value of skos:prefLabel per
language."
	        anymore.... because one day all indexing will be done using
URIs...
	        so we do
	        not need distinction between preferred and non preferred...
we may
	        represent
	        a concept with simply more labels per language.... E.g. which
one is
	        preferred between "canotto"@IT and "gommone"@IT ? why we
should
	        prefer an
	        acronym to a full form or viceversa? why we force people to
	        disambiguate into
	        a term for real synonyms such as "Argentina (fish)" and
"Argentina" ?
	       
	        This issue is out of scope for the current draft. AJM
	       
	        6.5.3. Unique Notations in Concept Schemes
	       
	         > <<<By convention, no two concepts in the same concept
scheme are
	        given the
	        same notation. If they were, it would not be possible to use
the
	        notation to
	        uniquely refer to a concept (i.e. the notation would become
	        ambiguous).>>>
	        I think that what should be really unique is the URI. This
sentence
	        is ok as
	        it only "By convention" notation unique.
	       
	        No action. SKB
	       
	         > 6.5.4. Notations and Preferred Labels
	         >
	         > Section 7: ok
	         >
	         > Section: 8.1. Preamble
	         >
	         > What about the proposal to change skos:broader into
	        skos:hasBroader (same for
	        narrower)? makes much more clear the use of the rt...
	       
	        The WG formally resolved ISSUE-82 by adding editorial changes
to the
	        documents highlighting the intended interpretation of broader
and
	        narrower. Hence the SKOS Reference now contains passages such
as "The
	properties skos:broader and skos:narrower are used to assert a direct
	        hierarchical link between two SKOS concepts. A triple <A>
	        skos:broader <B> asserts that <B>, the object of the triple,
is a
	        broader concept than <A>, the subject of the triple.
Similarly, a
	        triple <C> skos:narrower <D> asserts that <D>, the object of
the
	        triple, is a narrower concept than <C>, the subject of the
triple."
	AJM
	       
	         > 8.4. Integrity Conditions
	         >
	         > <<<skos:related is disjoint with the property
	        skos:broaderTransitive.>>>
	        Why it is not specified skos:related is disjoint with the
property
	        skos:narrowerTransitive?
	       
	        The assertion is not needed due to the fact that skos:related
is
	        symmetrical.
	        Added an explanatory noteSKB
	       
	         > I remember that skos:broader and skos:broaderTransitive
were of
	very
	        difficult comprehension by some users especially for the
hierarchical
	        relationships between them (myself I was thinking as should
be
	        skos:broaderTransitive subclass of skos:broader instead of
the
	        opposite). In
	        order to make this more comprehensible, would it be possible
to add
	an
	        examples such as "skos:broaderTransitive" may be the
"ancestor"
	        relationship.
	        This is transitive. A chidren relationships may be the
"father" and
	also
	        "adoptive father". "adoptive father" is not transitive...
This is a
	good
	        examples explaining the same situation as in SKOS. (maybe
help?)
	       
	        We feel this is out of scope for the SKOS Reference, but may
be
	        appropriate in the SKOS Primer. AJM
	       
	         >8.6.7. Reflexivity of skos:broader
	         >
	         > Example 39 (consistent): are we really sure we do not want
to set
	        skos:broader as anti-simmetric? in most of the cases when we
use
	        skos:broader
	        one concept is more generic than the other... so skos:broader
is
	        actually
	        used as non simmetric... do we have use cases for which
should be not
	like
	        this?
	       
	        Note that reflexivity and symmetry are two different
qualities.
	        Section 8.6.7 is about the reflexivity of skos:broader, and
does not
	        discuss symmetry. The WG formally resolved ISSUE-69 such that
	        skos:broader should be not normatively irreflexive, to leave
open the
	exploration of various design patterns for working with SKOS and OWL
	        in combination. AJM
	       
	       
	         > Section: 9. ok
	       
	         > Section: 10.
	       
	         > yes i wish actually to chain  skos:exactMatch... it may be
useful.
	       
	        Is this an explicit request for property chain axioms
relating to the
	        mapping properties? No action taken. SKB
	       
	        The WG formally resolved ISSUE-75 such that no property chain
axioms
	        shall be stated in the SKOS data model involving
skos:exactMatch,
	        because this is an area for further research. This does not
prevent
	        applications asserting their own property chain axioms and
drawing
	        their own conclusions. AJM
	       
	         > Appendix A  ok
	       
	         > Appendix B and C  ok
	       
	         > Another general comment would be: would not be better to
have more
	meaningful
	        examples instead of "foo" and "bar" ?
	       
	        Examples changed. SKB
	       
	       
	        --
	        Sean Bechhofer
	        School of Computer Science
	        University of Manchester
	        sean.bechhofer@manchester.ac.uk
	        http://www.cs.manchester.ac.uk/people/bechhofer
	       
	       
	       
	       
	
	
	
Received on Tuesday, 26 August 2008 16:06:36 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:07:54 UTC