- 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>
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