SKOS Reference Last Call Working Draft TODO List
Editorial Tasks
Add RDFa metadata?
WG Reviews
In the following, the original review text and comments are given, interleaved with responses. Those comments which I consider to have been addressed are rendered in strikethrough text.
Review from Guus Schreiber
This document is in good shape. I have no objections to publishing, provide the comments below are taken into account. Most comments are editorial.
GENERAL EDITING
Please change "foo/bar" examples.
Section 1.4 changed to dogs/cats. SKB
Section 1.6.1 changed to Person/hasParent/hasMother. SKB
Examples using foo/bar changed to love/adoration. SKB
"Integrity constraints/conditions": use one of these forms consistently
Changed in 9.6.2. SKB
"data" variably used as singular or plural, e.g. "SKOS data are" but also "some given data conforms to "
Usage changed consistently to plural. SKB
SYNOPSIS
"documented with various types of note" note => notes
I believe this is ok as it stands, with the plural form of types. SKB
STATUS
The 2nd "feature at risk" is unclear. We have to state the options and how the current choice might change (e.g. adding property-chaining axioms).
Done. SKB
SEC. 1
Consider to add a note about the overall design rationale behind SKOS, roughly covering the following issues: - wide coverage of KOSs required - therefore danger of SKOS schema overcommitment - WG rationale: if in doubt, don't include a formal constraint (least commitment strategy), but suggest usage convention or specialization instead => see Primer
The following has been added before Section 1.6 (How to Read this Document) 1.5 Design Rationale As discussed above, the notion of a Knowledge Organisation System encompasses a wide range of artefacts. There is thus a danger of overcommitment in the SKOS schema, which could preclude the use of SKOS for a particular application. In order to alleviate this, in situations where there is doubt about the inclusion of a formal constraint (for example, see discussion about <code>skos:hasTopConcept</code>), the constraint has not been stated formally. In such cases, usage conventions may be suggested, or specialisations of the SKOS vocabulary may be used in order to enforce constraints (see the SKOS PRIMER). SKB
1.2: suggest to change section title to "SKOS Overview"
Done. SKB
1.3
" ...I.e. SKOS is itself an OWL Full ontology." delete this part of the sentence as it is more or less a repetition of the earlier part.
Removed. SKB
I suggest to delete this paragraph. I think the issue is made clear enough in the rest of the text (also in 1.4), and this paragraph might be perceived as too opinionated.
Removed. SKB
1.4
Should we label this section explicitly as "Informative"?
Left as is. SKB
1.5
I find this unclear, in particular the "despite" part. I would reverse the argument: OWL Full does not require that <A> and <B> are explicitly defined as concepts, so the model is consistent. You could also argue that it is till an integrity constraint, as it disallows, for example, <A> to be a concept scheme. This is the only point in my review where I would appreciate some discussion.
The section has been rewritten. SKB 1.7
"an RDF graph" => "a RDF graph"
I believe that "an RDF Graph" is the correct usage. Adopting the wisdom of the crowd, Google gives 36,000 hits for "an RDF graph" and 785 for "a rdf graph". SKB
SEC. 2:
I suggest to make the table ordering more logical:
skos:Concept skos:ConceptScheme skos:inScheme skos:hasTopConcept skos:topConceptInScheme skos:altLabel skos:hiddenLabel skos:prefLabel skos:note skos:notation skos:changeNote skos:definition skos:editorialNote skos:example skos:historyNote skos:scopeNote skos:semanticRelation skos:broaderTransitive skos:broader skos:narrowerTransitive skos:narrower skos:related skos:Collection skos:OrderedCollection skos:member skos:memberList skos:mappingRelation skos:closeMatch skos:exactMatch skos:broadMatch skos:narrowMatch skos:relatedMatch
The table is ordered according to document section. We suggest to leave it as is. SKB
SEC. 4
Example 5:
<MyConcept> skos:topConceptInScheme <MyScheme> .
This statement could have been derived from the inverse semantics. Either remove or explicate in the text.
Triple removed. SKB
I find the name "skos:topConceptInScheme" too contrived. I prefer the natural inverse of "skos:hasTopConcept", namely "skos:topConceptOf". This is probably also eaier to understand and remember.
Changed to skos:topConceptOf. SKB
4.6.3 named RDF graphs
Explain (or refer to Primer) the issue of schema containment and potential use of SPARQL + named graphs
This section has been removed following discussion during the 19-08-08 telecon. SKB
SEC. 5
5.6.2
Instead of this single sentence I suggest to make a separate note about XL (e.g. "5.6.3 Defining label relations"), explicating in a few sentences why this is needed, just to point readers in the right direction.
New section added. SKB
5.6.4
This note feels a bit redundant as the point about language tags is already made at the end of 5.4
The note does provide illustrative examples, so I would suggest it remain. SKB
SEC. 7
"7" => "seven"
Done. SKB
Example 25: I suggest to refrain from using the construct "rdf:value" as it is so rarely used. If you really need it, you have to add an explanatory note + RDF ref.
Dealt with in the primer. See: http://lists.w3.org/Archives/Public/public-swd-wg/2008Aug/0025.html. SKB
SEC. 8
S26: skos:related is disjoint with the property skos:broaderTransitive.
Is skos:related also disjoint with skos:narrowerTransitive?
Yes, due to the fact that skos:related is symmetrical. Added explanatory note. SKB
8.6.4.
Explain briefly rationale why skos:related is not transitive.
Dealt with in the primer. See: http://lists.w3.org/Archives/Public/public-swd-wg/2008Aug/0025.html. SKB
8.6.6
"(e.g. simple query expansion algorithms)": delete "simple"
Done. SKB
8.6.10
First par: ".. distinct in nature, and that therefore a ..." => ".. distinct in nature. Therefore a ..."
Done. SKB
SEC 9
9.6
Suggest to explain briefly the use of "( .. )" notation in Turtle.
Done (in 9.5). SKB
SEC 10
S46: should skos:exactMatch not also be disjoint with skos:narrowMatch?
Symmetry of exactMatch will ensure this. Added explanatory note. SKB
10.6.7:
"link to individuals" to => two
Done. SKB
Obscure sentence. The point was already made above, suggest to delete this sentence.
Done. SKB
APPENDIX
"A property xl:labelRelation is defined. " => "The SKOS data model also defines the property xl:labelRelation."
Done. SKB
A1
I suggest to use "skos-xl:" in the examples instead of "xl". In this document it is not ambiguous, but in actual usage it might lead to reduced clarity. People will use the reference as a model.
Is this allowed? A hyphen in a namespace name? I have replaced with skosxl. SKB
A2.1
"an RDF plain literal": an => a
See above comment. SKB
A2.2
Shouldn't there be a definition c.q. semantic condition to define the cardinality of precisely 1 for xl:literalForm? BTW this would make the FuctionalProperty definition superfluous.
Condition S52 has been changed to reflect this. SKB
A2.4.1
"As stated above ...": this has actually not been stated yet, see previous comment.
See above response. SKB
I cannot parse this sentence (in particular the last part); please reformulate.
Reworded as: In other words, for a given plain literal <code>l</code>, there may <strong>not</strong> be an instance of <code>skosxl:Label</code> with <code>l</code> as a literal form. SKB
Reworded a bit more, to avoid possible misreading as a normative statement, as: In other words, for a given plain literal <code>l</code>, there might not be any instances of <code>skosxl:Label</code> with literal form <code>l</code>. AJM
A3.4.2
"Note the two integrity conditions on the SKOS labeling properties defined in Section 5." => "In Section 5 two integrity conditions were defined on the basic SKOS labeling properties."
Done. SKB
Review from Margherita Sini
Abstract: OK
Status of This Document: OK
Changes: OK
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
Meeting Minutes
Relevant meeting minutes:
http://www.w3.org/2008/07/01-swd-minutes.html -- resolved ISSUE 72, 73, 75, 86
http://www.w3.org/2008/06/17-swd-minutes.html -- resolved ISSUE 83
Implementation: Scheme Containment Properties (ISSUE-83)
ISSUE 83 was resolved at http://www.w3.org/2008/06/17-swd-minutes.html as per text at http://lists.w3.org/Archives/Public/public-swd-wg/2008May/0068.html
- TODO change data model in section 4
- TODO change prose in section 4 (add a new note?)
Implementation: Addition of Wording on URI Dereference Behaviour (ISSUE-86)
ISSUE 86 was resolved at http://www.w3.org/2008/07/01-swd-minutes.html
- Appendix on URI Dereference Behaviour
- Sean TODO
Text drafted: "URIs are used to identity resources of type skos:Concept and skos:ConceptScheme. The SKOS Reference does not require specific behaviour when dereferencing those URIs. It is, however, strongly recommended that publishers of vocabularies follow the guidelines for Best Practice Recipes [REF] and Cool URIS [REF]".
- Added appendix to working copy. 08/07/08
Implementation: Updates to Mapping Properties Section (ISSUES 72, 73, 75)
ISSUES 72, 73 and 75 were resolved at http://www.w3.org/2008/07/01-swd-minutes.html
- . Text describing resolution of ISSUES 72, 73 and 75
- ??? TODO
- Definition of closeMatch
- Justification of inclusion of closeMatch
- Update to RDF schema.
- . List of changes since last WD
- ??? TODO
Editorial: Identify Features at Risk
- . Identification of features AT RISK
- Sean TODO
- Initial list added. 08/07/08
Editorial: References Section
- TODO do the references section
- TODO link up all citations properly
Editorial: RDFa?
- TODO sprinkle some RDFA
SKOS Reference 2nd Working Draft TODO List
Set up master.html document under W3C CVS, including folding in post-edits from first WD
- Alistair --done
. Remove redundant appendices
- Alistair --done
Draft new section on notations
- Alistair --done
Redraft section on mapping properties
- Alistair --done
Draft new appendix on XL, and remove current section on label relations
- Guus TODO draft some wording and examples ???
Alistair incorporate content into draft & finish --done
Update section on semantic relations, including notes on irreflexivity, and wording to explain directionality of broader/narrower
- Sean --done
- Notes on irreflexivity added to Section 8.6.7. 27/05/08
- Sentence added in Section 8.1 27/05/08
Update sections referencing owl:imports
- Sean --done
- Email to primer editors pointing to proposed text. 15/05/08
- Propose removal of text from Section 4.6.2 from "In the example below, owl:imports..".
- Text stripped out of Section 4.6.2 27/05/08
Update namespace
- Alistair --done
Update vocabulary and quick access
- Alistair TODO
Review editors' comments in draft, remove/update as appropriate
- Alistair --done
Redraft formal schema (SKOS)
- Sean --done
Draft schema set up at [http://potato.cs.man.ac.uk/2008/05/skos SKOS RDF Schema] using Recipe 3.
Draft new formal schema (XL)
- Sean --done
Draft schema set up at [http://potato.cs.man.ac.uk/2008/05/skos-xl SKOS XL RDF Schema] using Recipe 3.
Run checks on formal schemas
- Alistair --done
Remove summary tables, then regenerate from schemas
- Alistair --done
- Create timestamped editors' draft
- Alistair TODO
Fix headings in timestamped editors' draft and number tables, examples etc.
- Alistair TODO
- Compile a list of changes since last WD
- Alistair TODO
- Notify WG and request review
- Alistair TODO
Email to editors of primer on any guidance for extending SKOS (was rules of thumb)
- Sean --done
- Mailed Antoine, Ed. 15/05/08 SKB
Response from Antoine 21/05/08. See [http://www.w3.org/2006/07/SWD/wiki/SkosPrimer20080221 SkosPrimer20080221].
Email to Ralph to propose namespace dereference setup and files
- Sean --done
- Mailed Ralph with proposal to provide short overview including generated table. 15/05/08 SKB.
Namespace to be http://www.w3.org/2008/05/skos. 19/05/08 SKB.
- SKOS/OWL Patterns
- Remove Appendix.
- Additional WG Note?
Terminology: Patterns may not be quite right.
Wiki page: [http://www.w3.org/2006/07/SWD/wiki/SKOS/SKOSandOWL SKOSandOWL]
Other Actions
- Namespaces setup for dereferencing (recipe 3)
- See K, L, T above re. formal schema.
- TODO Review section 1.2 "what is SKOS?" for section numbers and content
- TODO note on unique preflabels in schemes
- --done examples consistent, not consistent, entailment, non-entailment