- From: Thomas Baker <baker@sub.uni-goettingen.de>
- Date: Mon, 5 Jan 2009 14:58:46 +0100
- To: SWD Working Group <public-swd-wg@w3.org>
Ed, Antoine,
I have reviewed the 16 December version of the SKOS Primer [1].
When in doubt, I consulted the SKOS Reference at [3].
Basically, the Primer is in great shape - congratulations
to the authors for a fine piece of work with lots of nice
examples!
As agreed with Ed and Antoine, I made numerous small editorial
changes, saved the new version as [2], and attach a diff
output (below) with commentary.
Most of those changes I made are very minor. The "minor
editorial changes" include the following:
-- Changed spelling of "modeling" and "labeling" (instead of
"modelling" and "labelling") for consistency with SKOS
Reference.
-- Corrected references to consistently cite exact versions (e.g.,
RDF Primer of 10 February 2004); in all cases the "latest
versions" were already listed correctly.
Beyond the things that could easily be fixed, I noted several
more substantive issues:
-- I could not review Figures 4.5.1 and 4.5.2, which did not
properly display in my browser.
-- The links for the ISO 2788 and ISO 5964 references are broken.
-- I noted the stylistic use of "you" in addressing the reader in
several places, as in "it allows you to link...". I have no
objections but wanted to check whether this is in accordance
with W3C style guidelines. Ralph, do you happen to know?
-- The Primer uses the http://purl.org/dc/elements/1.1/
namespace and cites http://dublincore.org/documents/dces/.
I suggest using the http://purl.org/dc/terms/ namespace and
citing http://dublincore.org/documents/dcmi-terms/ (a large
Web document which also documents the /1.1/ namespace).
This would mean either mapping dc: to /dc/terms/ (in Section
1.1) or introducing a second namespace, such as dct:, as in
dct:subject. Note that dct:title and dct:date have literal
ranges, and dct:subject and dct:creator have non-literal
ranges, so all of the existing examples would still be
correct (e.g., X dc:subject ex1:platypus) except for one:
X ex:madagascarFishEagle dc:creator "John smith".
Using http://purl.org/dc/elements/1.1/creator, which has no
range, this example is not incorrect. Indeed, it is not at
all incorrect to use /1.1/ terms for all of the examples,
as they currently are. The point is that DCMI is gently
promoting the use of the dct: equivalents of the fifteen
elements because of their formal ranges.
The example above could either be changed to use dct:creator
with a blank node and foaf:name, or it could remain as is
(dc:creator) with the addition of the /dc/terms/ namespace for
dct:subject, etc. Or, of course, it would not be incorrect
to leave the examples as they are, using the /elements/1.1/
namespace throughout.
-- Section 4.2 uses the notion of a "structured RDF value".
I feel ambivalent as to whether the phrase "structured
value" is helpful. I note that a Google search on the
exact phrase "structured RDF value" (in quotes) yields
only one hit -- the RDF Primer, and a search on RDF and
structured and value yields mostly material from 2004 or
before. If we use it here, we would effectively resurrect
its use. Do we really want to do this, or are there other
ways of expressing this that are more up-to-date?
I note that use of the phrase "structured value" is
orthogonal to the question of whether or not to use
rdf:value.
-- In section 4.3, it looks like a mistake to say:
ex:FAO rdf:type skos:Concept;
skos:prefLabel ex:FAOlabel1;
skos:altLabel ex:FAOlabel2.
ex:FAOlabel2 skos-xl:labelRelation ex:FAOlabel1.
so I went ahead and changed this to use skos-xl:
ex:FAO rdf:type skos:Concept;
skos-xl:prefLabel ex:FAOlabel1;
skos-xl:altLabel ex:FAOlabel2.
ex:FAOlabel2 skos-xl:labelRelation ex:FAOlabel1.
-- I am slightly uneasy with various references in the text
to "SKOS semantics" (e.g., 2.2.1) given that SKOS Reference
does not itself use this phrase. SKOS Reference always
refers to the "SKOS data model", and SKOS does not have
its own "semantics" specification in the way that RDF has
"RDF Semantics".
-- The wording of
They have as their ranges [RDF-CONCEPTS] RDF plain literals,
which means that they link a skos:Concept to a character
string, not to another full-fledged RDF resource identified
with a URI.
does not allow for the possibility of linking to a blank node.
-- I was just wondering whether we have evidence that the following
use is really the "most common"...?
The most common use of hidden labels is to
include misspelled variants of other lexical labels.
-- With regard to notations (Section 4.6)
These are language-independent symbols, designed to allow
an easy re-use of the whole vocabulary in different
languages. They are typically composed of digits,
complemented with punctuation signs and other characters,
as in the following UDC example:
The wording seems to imply that notations are
"language-independent" by _definition_, not just
_typically_. It seems a bit stronger than the SKOS Reference
formulation that notions are "not normally recognizable
as a word or sequence of words in any natural language" [*].
[*] http://www.w3.org/2006/07/SWD/SKOS/reference/20081001/#notations
-- I wasn't sure about the word "treatments" in the following:
This approach can be especially useful if a KOS publisher
wants to provide users with treatments that are specific to
the KOS's notation scheme.
Does this mean specifications? interpretations? processing rules?
-- The Example in section 5.1 says:
<http://www.w3.org/People/Berners-Lee/card#i> rdf:type foaf:Person;
foaf:name "Timothy Berners-Lee";
rdfs:label "Tim Berners-Lee";
skos:prefLabel "Tim Berners-Lee"@en.</code></pre>
While not incorrect, the example seems redundant because
rdfs:label is a superproperty both of skos:prefLabel and
(as the text says) foaf:name - which as a reader I find
slightly confusing.
-- I'm not sure the following is phrased quite right (Section 3.1):
Had the concepts been assigned other information, such
as semantic relationships to other concepts, or notes,
these would be merged as well, resulting in completely
new conceptual entities.
The idea is not that some new entity would be _created_
by merging asserted semantic relationships from multiple
sources (which is implied by "resulting in new... entities")
but that the _existing_ entity would in effect be overlaid
with different associations and thus would acquire
conceptually new meanings. Maybe there's a better way to
put this?
-- I find the following sentence in Section 3.2 to be unclear:
For example, a SKOS publisher can choose to locally extend
an existing concept scheme, and then publish the extension
with the linkages intact.
What does "publish the extension" mean, and what "linkages"
are remaining intact?
-- With regard to mapping properties, instead of
Instead, their motivation is expected to be tightly related
to a specific application that requires them to cope,
say, with conceptual redundancy resulting from several
KOSs coexisting.
I suggest:
Mapping properties are expected to be useful in applications
that use multiple, conceptually overlapping KOSs.
-- The second sentence in the following is not very clear (and is not
a complete sentence):
By convention, mapping relationships are also expected
to be asserted between concepts that belong to
different concept schemes. Although specific scenarios
(such as enriching a concept scheme that lacks desired
semantic structure) may sometimes necessitate create
mappings within a scheme.
If mappings within a scheme were needed, one would normally use semantic
relation properties. Is the point here that one might want to enrich
_somebody else's_ concept scheme?
-- In Section 3.2, referring to the first example concept scheme as a
"reference concept scheme" needlessly introduces a potential source
of confusion (what is a "reference concept scheme"?) -- especially
when it talks about "referencing" the "reference ex1:cats concept".
Calling them something like Concept Schemes A and B might be clearer.
-- The final sentence in the following is unclear:
Finally, the reader should be aware that according to SKOS semantics, the
mapping properties that "mirror" a given semantic relation property are also
sub-properties of it in the RDFS sense. For instance,
<code>skos:broadMatch</code> is a sub-property of <code>skos:broader</code>.
Consequently, every assertion of <code>skos:broadMatch</code> between two
concepts leads by inference to asserting a <code>skos:broader</code> between
these concepts. With concept scheme extension discussed in the previous
section, this is one of the situations where the SKOS basic semantic
relationships defined in Section 2.2 can hold across different concept
schemes.
Looking back at the "previous section" I was unsure what this
sentence is actually saying and suggest that it be reworded to
make this explicit.
I note that the following still would need to be edited before
publication:
-- "Status of this Document"
-- "Acknowledgments"
-- A few in-line comments (<!-- ... -->).
-- Updated reference to SKOS Reference, when available
-- Remove @@ regarding exactMatch, etc.
Detailed changes (starting with the more significant and ending with the
minor edits) follow below.
Tom
[1] http://www.w3.org/2006/07/SWD/wiki/SKOS/DraftPrimer?action=AttachFile&do=get&target=SKOSPrimer-081216.html
[2] http://www.w3.org/2006/07/SWD/wiki/SKOS/DraftPrimer?action=AttachFile&do=get&target=SKOSPrimer-090105.html
[3] http://www.w3.org/2006/07/SWD/SKOS/reference/20081001/
======================================================================
Diff output, by type of change, from "significant" to "minor"
======================================================================
Editorial suggestions of some substance (see explanations above)
1443,1444c1445,1446
< skos:prefLabel ex:FAOlabel1;
< skos:altLabel ex:FAOlabel2.
---
> skos-xl:prefLabel ex:FAOlabel1;
> skos-xl:altLabel ex:FAOlabel2.
1935,1938c1937,1940
< <dd><cite><a href="http://dublincore.org/documents/dces/">Dublin Core
< Metadata Element Set</a></cite>, Version 1.1, 14 January 2008. <a
< href="http://dublincore.org/documents/dces/">Latest version</a>
< available at http://dublincore.org/documents/dces/ . </dd>
---
> <dd><cite><a href="http://dublincore.org/documents/2008/01/14/dcmi-terms/">DCMI
> Metadata Terms</a></cite>, 14 January 2008. <a
> href="http://dublincore.org/documents/dcmi-terms/">Latest version</a>
> available at http://dublincore.org/documents/dcmi-terms/ . </dd>
1735c1737
< <p class="note"><strong>Note—messing with the vocabulary:</strong> In
---
> <p class="note"><strong>Note on tampering with the SKOS vocabulary itself:</strong> In
Tom says: "Messing with the vocabulary" has an appealing
slangy flavor, but the word "tampering" is safer.
----------------------------------------------------------------------
Editorial changes that should be checked more closely
729c729
< <p>As mentioned in the SKOS semantics [<cite><a
---
> <p>As described in the <cite>SKOS Reference</cite> [<cite><a
1004c1004,1005
< <p>It is possible to map these two concept schemes using the mapping
---
> <p>It is possible to map the concepts in <code>ex1:referenceAnimalScheme</code>
> to the concepts in <code>ex2:eggSellerScheme</code> using the mapping
1070c1071
< mapping properties that "mirror" a given semantic property are also
---
> mapping properties that "mirror" a given semantic relation property are also
1156c1158
< instances of <code>owl:Ontology</code>. This in turn results in an OWL Full
---
> inferred to be instances of <code>owl:Ontology</code>. This in turn results in an OWL Full
1479c1481
< maintainer, or by an indexer who is using a KOS. For example, if <!--a concept
---
> maintainer, or by an indexer who is using a KOS—for example, if <!--a concept
1488c1490
< retrieval task. For example if a given document is indexed with two distinct
---
> retrieval task—for example, if a given document is indexed with two distinct
1496,1497c1498,1499
< <p>Post-coordination as an information retrieval activity can lend itself
< to—indirect—representation as a SPARQL query to access RDF data [<cite><a
---
> <p>Post-coordination as an information retrieval activity lends itself
> to <em>indirect</em> representation as a SPARQL query to access RDF data [<cite><a
1674,1676c1676,1678
< <code>skos:prefLabel</code>, in combination with private use language
< (sub-)tags as defined by <cite>RFC4646</cite> [<cite><a
---
> <code>skos:prefLabel</code>, in combination with private-use language
> tags (or subtags) as defined by <cite>RFC 4646</cite> [<cite><a
2088,2090c2090,2092
< already said in this document, SKOS can be used—eventually with some
< appropriate extension—for other types of KOS, or thesauri that do not
< follow the ISO prescriptions.</p>
---
> already said in this document, SKOS can be used—possibly with
> appropriate extensions—for other types of KOS, or thesauri that do not
> follow the ISO guidelines.</p>
2116,2117c2118,2119
< labels, it is not possible to explicitly reflect term-forming
< mechanisms such as qualification. For this, and for other cases of
---
> labels, it is not possible to express term-forming
> mechanisms such as qualification formally and explicitly. For this, and for other cases of
2172,2173c2174,2175
< general KOS practice—of which thesauri constitute an important but
< only partial account. SKOS instead focuses on separating explicitly
---
> general KOS practice—of which thesauri are only part.
> SKOS instead focuses on separating explicitly
----------------------------------------------------------------------
Systematic spelling of "modeling" and "labeling"
174c174
< combined with other modelling vocabularies.</p>
---
> combined with other modeling vocabularies.</p>
298c298
< <li><a href="#seccombining">5 Combining SKOS with other Modelling
---
> <li><a href="#seccombining">5 Combining SKOS with other Modeling
373c373
< discusses the use of SKOS in conjunction with other modelling approaches,
---
> discusses the use of SKOS in conjunction with other modeling approaches,
518c518
< thereby enables a simple form of multilingual labelling. This is done by
---
> thereby enables a simple form of multilingual labeling. This is done by
840c840
< literals, however, is the ability to use language tags, as done for labelling
---
> literals, however, is the ability to use language tags, as done for labeling
962c962
< possibly adhere to different modelling principles [<cite><a
---
> possibly follow different modeling principles [<cite><a
1218c1220
< making SKOS compatible with a broad range of KOS modelling approaches. These
---
> making SKOS compatible with a broad range of KOS modeling approaches. These
1286c1288
< SKOS labelling properties) can be used with non-conceptual resources.</p>
---
> SKOS labeling properties) can be used with non-conceptual resources.</p>
1414c1416
< use of SKOS lexical labelling properties, e.g. <code>skos:prefLabel</code>,
---
> use of SKOS lexical labeling properties, e.g. <code>skos:prefLabel</code>,
1439c1441
< href="#seclabel">literal-based labelling constructs</a>. Finally, these
---
> href="#seclabel">literal-based labeling constructs</a>. Finally, these
1457c1459
< compatible with the standard SKOS labelling practice. If an instance of
---
> compatible with the standard SKOS labeling practice. If an instance of
1674,1676c1676,1678
< possible to use one SKOS labelling property, for instance
< <code>skos:prefLabel</code>, in combination with private use language
< (sub-)tags as defined by <cite>RFC4646</cite> [<cite><a
---
> possible to use one SKOS labeling property, for instance
> <code>skos:prefLabel</code>, in combination with private-use language
> tags (or subtags) as defined by <cite>RFC 4646</cite> [<cite><a
1696c1698
< modelling approaches. As such it is hoped that the current vocabulary
---
> modeling approaches. As such it is hoped that the current vocabulary
1756c1758
< <h2 id="seccombining">5 Combining SKOS with other Modelling Approaches</h2>
---
> <h2 id="seccombining">5 Combining SKOS with other Modeling Approaches</h2>
1760,1761c1762,1763
< used on the Semantic Web as a complement to other modelling vocabularies.
< This section gives examples of re-using SKOS labelling properties to describe
---
> used on the Semantic Web as a complement to other modeling vocabularies.
> This section gives examples of re-using SKOS labeling properties to describe
1768c1770
< with other modelling approaches. Users not having such a requirement may skip
---
> with other modeling approaches. Users not having such a requirement may skip
1773c1775
< <p>It is possible to use SKOS labelling properties to label resources that
---
> <p>It is possible to use SKOS labeling properties to label resources that
1856c1858
< to handle (some forms of) metamodelling within a description-logic framework.
---
> to handle (some forms of) metamodeling within a description-logic framework.
1869c1871
< latter problem by offering some form of metamodelling. </li>
---
> latter problem by offering some form of metamodeling. </li>
2110c2112
< <td><em>Concepts</em> are the central modelling primitive of SKOS.
---
> <td><em>Concepts</em> are the central modeling primitive of SKOS.
2221c2223
< <code>skos:notation</code> property, or by using simple labelling
---
> <code>skos:notation</code> property, or by using simple labeling
----------------------------------------------------------------------
KOSs (plural of KOS)
317c317
< representing semi-formal <em>knowledge organization systems</em> (KOS), such
---
> representing semi-formal <em>knowledge organization systems</em> (KOSs), such
964c964
< a key advantage of making KOS available on the Semantic Web using SKOS. </p>
---
> a key advantage of making KOSs available on the Semantic Web using SKOS. </p>
1343c1345
< for some cases, <em>e.g.</em> when KOS are mainly intended as navigation
---
> for some cases, e.g. when KOSs are mainly intended as navigation
But note:
1664c1666
< treatments that are specific to the KOS' notation scheme. For instance, many
---
> treatments that are specific to the KOS's notation scheme. For instance, many
----------------------------------------------------------------------
"Note -- " as opposed to "Note on", which looks nicer, in my opinion...:-)
558c558
< <p class="note"><strong>Note—upward posting:</strong> It is also possible
---
> <p class="note"><strong>Note on upward posting:</strong> It is also possible
646c646
< <p class="note"><strong>Note—<code>skos:broader</code> direction:</strong>
---
> <p class="note"><strong>Note on <code>skos:broader</code> direction:</strong>
653c653
< <p class="note"><strong>Note—implicit
---
> <p class="note"><strong>Note on implicit
685c685
< <p class="note"><strong>Note—not transitive vs. intransitive</strong>: the
---
> <p class="note"><strong>Note on not transitive vs. intransitive</strong>: the
738c738
< <p class="note"><strong>Note—(non-)transitivity of
---
> <p class="note"><strong>Note on (non-)transitivity of
754c754
< <p class="note"><strong>Note—mixing hierarchy with association:</strong>
---
> <p class="note"><strong>Note on mixing hierarchy with association:</strong>
1139c1141
< <p class="note"><strong>Note—<code>owl:imports</code> and re-using
---
> <p class="note"><strong>Note on <code>owl:imports</code> and re-using
1030c1031
< <p class="note"><strong>Note—<code>skos:exactMatch</code> vs.
---
> <p class="note"><strong>Note on <code>skos:exactMatch</code> vs.
1619c1621
< <p class="note"><strong>Note—on supposed "transitiveness
---
> <p class="note"><strong>Note on supposed "transitiveness
1735c1737
< <p class="note"><strong>Note—messing with the vocabulary:</strong> In
---
> <p class="note"><strong>Note on tampering with the SKOS vocabulary itself:</strong> In
----------------------------------------------------------------------
"Like" versus "such as" (really not a big deal, but "such as" is sometimes more precise)
328c328
< or in combination with more formal languages like the Web Ontology Language
---
> or in combination with more formal languages such as the Web Ontology Language
951c951
< concepts. Such <em>mappings</em> are crucial for applications like
---
> concepts. Such <em>mappings</em> are crucial for applications such as
1051c1052
< the concepts been assigned other information, like semantic relationships to
---
> the concepts been assigned other information, such as semantic relationships to
1133,1134c1134,1136
< re-assert the RDF statements for the <code>ex1:cats</code> concept, e.g., its
< <code>skos:prefLabel</code>. Assuming <code>ex1:cats</code> has been
---
> re-assert things such as the <code>skos:prefLabel</code> of the
> the <code>ex1:cats</code> concept.
> Assuming <code>ex1:cats</code> has been
1191c1193
< fundamental in many KOS applications, like document indexing and document
---
> fundamental in many KOS applications, such as document indexing and document
1291c1293
< collection: such as when concepts are listed in alphabetical or chronological
---
> collection, such as when concepts are listed in alphabetical or chronological
1483,1484c1485,1486
< an indexer takes two existing concepts from a concept scheme, like "Bicycles"
< and "Repairing", and explicitly combines them with a given syntax like
---
> an indexer takes two existing concepts from a concept scheme, such as "Bicycles"
> and "Repairing", and explicitly combines them with a given syntax such as
1686,1687c1688,1689
< benefit from notation-specific mechanisms in SKOS tools—for instance
< display procedures. This would indeed require different actors to agree on
---
> benefit from notation-specific mechanisms (such as display procedures) in SKOS tools.
> This would indeed require different actors to agree on
1889c1891
< <p>However, solutions for such problems have been proposed, like named graphs
---
> <p>However, solutions for such problems have been proposed, such as named graphs
--------------------------------------------------------------------
Minor editorial changes
172c172
< between concept labels can be specified. Finally, the SKOS vocabulary itself
---
> can be specified between concept labels. Finally, the SKOS vocabulary itself
177c177
< href="http://www.w3.org/TR/skos-reference">SKOS Reference</a>, which gives
---
> href="http://www.w3.org/TR/skos-reference">SKOS Reference</a>, which provides
404c404
< examples. Generally, these namespaces could be declared as in the the
---
> examples. Generally, these namespaces could be declared as in the
527c527
< can only have one such label per language tag, as it is mentioned in <a
---
> can only have one such label per language tag, as explained in <a
854c854
< <pre class="code">ex:madagascarFishEagle dc:creator "John smith".</pre>
---
> <pre class="code">ex:madagascarFishEagle dc:creator "John Smith".</pre>
876c876
< <p>Once the concept scheme resource has been created, it can be linked to the
---
> <p>Once the concept scheme resource has been created, it can be linked with the
888c888
< <p>Finally, for providing an efficient access to the entry points of
---
> <p>In order to provide an efficient access to the entry points of
902c902
< For example, as mentioned in <a href="#seclabel">Section 2.2</a>, it is for
---
> For example, as described in <a href="#seclabel">Section 2.2</a>, it is for
923c923
< while it is usually acknowledged that a KOS consists of both its concepts and
---
> whereas a KOS is usually seen as consisting of both its concepts and
954c954
< reconciled—examples can be found in the <a
---
> reconciled; examples can be found in the <a
960c960
< from different schemes have comparable meanings, and to make precise how
---
> from different schemes have comparable meanings, and to specify how
1057,1058c1058,1059
< different scope. One can indeed anticipate that mapping relationships are
< much less <em>inherent</em> to the meaning of the concepts they involve. From
---
> different scope. One might say that mapping relationships are
> less <em>inherent</em> to the meaning of the concepts they involve. From
1095,1097c1096,1098
< <p>Extension of a KOS can be especially useful when its designers (or third
< party KOS publishers) want to achieve a better coverage of a (sub-)domain,
< while adhering to the principles that guided the design of the existing
---
> <p>Extension of a KOS can be especially useful when its designers (or
> third-party KOS publishers) want to achieve a better coverage of a domain or sub-domain,
> while following the principles that guided the design of the existing
1040c1041
< <code>ex2:animals</code>. If this equivalence relation was represented using
---
> <code>ex2:animals</code>. If this equivalence relation were represented using
1101,1102c1102,1103
< vocabulary) is designed to cover several domains, and its designers want to
< allow specific applications to operate on given selections of concepts.</p>
---
> vocabulary) is designed to cover several domains and its designers want to
> allow specific applications to operate on given subsets of concepts.</p>
1142c1144
< property provides a mechanism for importing the assertions in one OWL
---
> property provides a mechanism for importing the assertions of one OWL
1172c1174
< even though <code>ex1:referenceAnimalScheme</code> contains the triples </p>
---
> even though <code>ex1:referenceAnimalScheme</code> contains the triple</p>
1345c1347
< terms" as instance of <code>skos:Concept</code>, and to use normal semantic
---
> terms" as instances of <code>skos:Concept</code>, and to use normal semantic
1425c1427
< class that allows to treat labels as first-order RDF resources. Each instance
---
> class that allows labels to be treated as first-order RDF resources. Each instance
1550c1552
< <p>As mentioned in <a href="#sechierarchy">Section 2.3.1</a>, the properties
---
> <p>As described in <a href="#sechierarchy">Section 2.3.1</a>, the properties
1627c1629
< and only if everytime P holds between two resources, then Q also holds
---
> and only if every time P holds between two resources, then Q also holds
1751c1753
< feedback, helping to enhance the quality of published extensions...</p>
---
> feedback, helping to enhance the quality of published extensions.</p>
1816c1818
< <code>ex:Painting</code> in a art vocabulary) are in OWL terms
---
> <code>ex:Painting</code> in an art vocabulary) are in OWL terms
1876,1877c1878,1879
< <p>In a context of networked KOSs, some applications may require tracking
< provenance or ownership of SKOS statements, for instance for trust purposes.
---
> <p>In a context of networked KOSs, some applications may require
> the provenance or ownership of SKOS statements to be tracked, for instance for trust purposes.
1894,1895c1896,1897
< a Dataset, which enables to create SPARQL queries dealing with some form of
< provenance/containment. Continuing the example of <a
---
> a Dataset, which enables the creation of SPARQL queries dealing with some form of
> provenance or containment. Continuing the example of <a
2083c2085
< design of SKOS vary from ISO recommendations. It is hoped that this will help
---
> design of SKOS varies from ISO recommendations. It is hoped that this will help
2149c2151
< term) express that a term's meaning is more general than an other's.
---
> term) express that a term's meaning is more general than another's.
2151c2153
< associative link holds between meanings, that can be useful for
---
> associative link holds between meanings, which can be useful for
2192c2194
< palliate this shortcoming, e.g. by specializing
---
> address this shortcoming, e.g. by specializing
2201c2203
< <td>SKOS allows representing groupings of concepts. But it focuses on
---
> <td>SKOS allows the representation of groupings of concepts. But it focuses on
2230,2231c2232,2233
< <td>SKOS is influenced by the possibility to have several KOSs
< co-existing. A <code>ConceptScheme</code> class is proposed to
---
> <td>SKOS is influenced by the possibility of having several KOSs
> co-exist. A <code>ConceptScheme</code> class is proposed to
----------------------------------------------------------------------
"This version" URIs (instead of "latest version" URIs)
1924c1926
< <dd><cite><a href="http://www.w3.org/TR/cooluris/">Cool URIs for the
---
> <dd><cite><a href="http://www.w3.org/TR/NOTE-cooluris-20081203/">Cool URIs for the
1955c1957
< <dd><cite><a href="http://www.w3.org/TR/rdf-syntax-grammar/">RDF/XML
---
> <dd><cite><a href="http://www.w3.org/TR/2004/REC-rdf-syntax-grammar-20040210/">RDF/XML
1962c1964
< <dd><a href="http://www.w3.org/TR/swbp-vocab-pub/"><cite>Best Practice
---
> <dd><a href="http://www.w3.org/TR/2008/NOTE-swbp-vocab-pub-20080828/"><cite>Best Practice
1971c1973
< <dd><cite><a href="http://www.w3.org/TR/owl-ref/">OWL Web Ontology
---
> <dd><cite><a href="http://www.w3.org/TR/2004/REC-owl-ref-20040210/">OWL Web Ontology
1978c1980
< <dd><cite><a href="http://www.w3.org/TR/rdf-primer/">RDF
---
> <dd><cite><a href="http://www.w3.org/TR/2004/REC-rdf-primer-20040210/">RDF
1985c1987
< <dd><cite><a href="http://www.w3.org/TR/rdf-concepts/">Resource
---
> <dd><cite><a href="http://www.w3.org/TR/2004/REC-rdf-concepts-20040210/">Resource
2012c2014
< <dd><cite><a href="http://www.w3.org/TR/skos-ucr/">SKOS Use Cases and
---
> <dd><cite><a href="http://www.w3.org/TR/2007/WD-skos-ucr-20070516/">SKOS Use Cases and
2019c2021
< <dd><cite><a href="http://www.w3.org/TR/rdf-sparql-query/">SPARQL Query
---
> <dd><cite><a href="http://www.w3.org/TR/2008/REC-rdf-sparql-query-20080115/">SPARQL Query
2036c2038
< <dd><a href="http://www.w3.org/TeamSubmission/turtle/"><cite>Turtle -
---
> <dd><a href="http://www.w3.org/TeamSubmission/2008/SUBM-turtle-20080114/"><cite>Turtle -
--
Tom Baker <tbaker@tbaker.de>
Received on Monday, 5 January 2009 13:59:29 UTC