This is an archive of an inactive wiki and cannot be modified.

TableOfContents()

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

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.e. it is appropriate (if one has the time, effort and need) to manually re-engineer a thesaurus or classification scheme as a formal OWL ontology, using the "concepts" of the thesaurus as a starting point for creating classes, properties and individuals in the ontology, and using the informal hierarchies and association networks of the thesaurus as a starting point for creating the axioms and facts of the ontology. However, OWL is a formal ontology language, and it does not by itself provide a natural or suitable data model for expressing a thesaurus or classification scheme. I.e. it is not appropriate to express the "concepts" of a thesaurus or classification scheme directly as classes of an ontology, nor to express the informal (broader/narrower) hierarchy of a thesaurus directly as a set of class subsumption axioms. 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.

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

These statements are not integrity conditions. I.e. the graph below is perfectly consistent with the SKOS data model, despite the fact that <A> and <B> have not been explicitly declared as instances of skos:Concept.

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

For an application that needs to identify labels using URIs, consider using the SKOS eXtension for Labels defined in Appendix A.

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

Generally speaking, using owl:sameAs in this way will lead to inappropriate inferences, which may sometimes (but not always) be detectable by checking consistency with the SKOS data model.

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

Second, the function is not surjective. In other words, there may be no instances of xl:Label with a literal form corresponding to a given plain literal.

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:

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

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

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

Editorial: Identify Features at Risk

Editorial: References Section

Editorial: RDFa?

SKOS Reference 2nd Working Draft TODO List

  1. Set up master.html document under W3C CVS, including folding in post-edits from first WD

    • Alistair --done

  2. . Remove redundant appendices

    • Alistair --done

  3. Draft new section on notations

    • Alistair --done

  4. Redraft section on mapping properties

    • Alistair --done

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

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

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

  8. Update namespace

    • Alistair --done

  9. Update vocabulary and quick access

    • Alistair TODO

  10. Review editors' comments in draft, remove/update as appropriate

    • Alistair --done

  11. Redraft formal schema (SKOS)

  12. Draft new formal schema (XL)

  13. Run checks on formal schemas

    • Alistair --done

  14. Remove summary tables, then regenerate from schemas

    • Alistair --done
  15. Create timestamped editors' draft
    • Alistair TODO

  16. Fix headings in timestamped editors' draft and number tables, examples etc.

    • Alistair TODO
  17. Compile a list of changes since last WD
    • Alistair TODO
  18. Notify WG and request review
    • Alistair TODO

  19. Email to editors of primer on any guidance for extending SKOS (was rules of thumb)

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

  21. SKOS/OWL Patterns

Other Actions

  1. Namespaces setup for dereferencing (recipe 3)
    • See K, L, T above re. formal schema.
  2. TODO Review section 1.2 "what is SKOS?" for section numbers and content
  3. TODO note on unique preflabels in schemes
  4. --done examples consistent, not consistent, entailment, non-entailment

SKOS/Reference/Planning (last edited 2008-08-20 16:16:30 by SeanBechhofer)