Copyright ©2008 W3C® (MIT, INRIA, Keio), All Rights Reserved. W3C liability, trademark, document use and software licensing rules apply.
This document outlines the way in which the Semantic Web Deployment Working Group addressed the comments submitted during the SKOS Last Call period.
During the Last Call period of SKOS, a number of comments were received from both inside and outside of the W3C. This document summarizes those comments and describes the ways in which the comments were addressed by the Semantic Web Deployment Working Group.
Note that the majority of this document is automatically generated from the Working Group's database of comments. As such, it may contain typographical or stylistic errors. If so, these are contained in the original submissions, and the SWD Working Group elected to not change these submissions.
In a number of cases, no response was received from the initial commenter. In these cases, issues have been postponed or closed assuming agreement with the proposed resolution.
This document is a product of the W3C's SWD Working Group. This document may be updated, replaced or rendered obsolete by other W3C documents at any time. It is inappropriate to use this document as reference material or to cite it as other than "work in progress". This document is work in progress and does not imply endorsement by the W3C membership.
This document has been produced by the W3C Semantic Web Deployment Working Group as part of the Semantic Web Activity. The goals of the Semantic Web Deployment Working Group are discussed in the Semantic Web Deployment Working Group.
Please send detailed comments on this document to ??@w3.org. We cannot guarantee a personal response, but we will try when it is appropriate.
A list of current W3C Recommendations and other technical documents can be found at http://www.w3.org/TR.
| Issue | Action | Commenter Feedback | Change Type | Status | Notes |
|---|---|---|---|---|---|
| 129: S9 skos:ConceptScheme is disjoint with skos:Concept | Accept | Accept | None | Closed | As you discuss, in the SKOS data model, a concept scheme is viewed as an aggregation of a number of Concepts and we have chosen to make Concept and ConceptScheme disjoint. This does then require the introduction of additional URLs to identify the scheme and the concepts but we believe that maintaining a separation between the two notions aids clarity and promotes interoperability. We propose to *close* this issue, making no change to the document. I hope that you are able to live with this. |
| 130: skos:hasTopConcept and skos:topConceptOf | Accept | None | None | Closed | A typical use of this property is to find and display the top levels of a thesaurus in a tree browsing interface. Because this is such a common requirement, we felt that it makes sense to have a property such as skos:hasTopConcept which is designed to complement the broader/narrower links in the scheme. If you require some other mechanism for identifying entry points into a concept scheme which is not dependent on broader/narrower links, we suggest you define a custom property for this purpose. We propose to make no change to the current specification. |
| 131: mappings with a boolean expression | Accept | Accept | None | Postponed | The Working Group has considered mappings between concepts and Boolean-like expressions. This fell within the scope of two issues: [ISSUE-39] and [ISSUE-40]. In [1] it was proposed not to include any boolean-like grouping constructs in SKOS, because this would require a substantial addition to the theoretical foundations of SKOS. This was discussed during the 2007-12-18 telecon and became part of the resolution to ISSUE-39 adopted by the Working Group. Any third party is, of course, free to define an extension for SKOS which provides a vocabulary for complex, boolean-like mapping expressions, and which ideally would also develop the necessary theory to allow those expressions to be used in query translation software. This, however, has been deemed out of scope for the current SKOS Recommendation Track work. |
| 132: error in section 1.7 example | Accept | None | Editorial | Closed | Fixed in draft |
| 133: domain of skos:inScheme | Accept | Accept | Editorial | Closed | We propose to make an editorial change to the SKOS Reference, adding a note to the end of section 4 along the lines of: """ 4.6.5. Domain of skos:inScheme Note that no domain is stated for the property skos:inScheme. I.e. the domain is effectively the class of all resources (rdfs:Resource). The decision not to state any domain has been made to provide some flexibility, enabling extensions to SKOS to define new classes of resource but still use skos:inScheme to link them to a skos:ConceptScheme. See also Example 84 below. """ Also note that example 84 in section A.2.4.2 illustrates the use of skos:inScheme with skosxl:Label. |
| 134: owl:inverseOf | Accept | None | Editorial | Closed | We agree, and propose to amend the SKOS Reference accordingly. |
| 135: rdfs:label | Accept | Accept | Editorial | Closed | In the current schema, these [skos:prefLabel, skos:altLabel, skos:hiddenLabel] are asserted to be instances of owl:DatatypeProperty. On reflection, we feel that it is more appropriate to type these as owl:AnnotationProperty and retain the subproperty relationship. Although this will still violate an OWL DL constriant (no subproperty relationships are allowed on annotation properties), it is likely that changes in OWL 2 will allow relationships between annotation properties. It may then be possible to represent SKOS in terms which conform to OWL 2 with minimal changes. The Working Group thus propose to change the type of the SKOS labelling properties to owl:AnnotationProperty, and *postpone* this issue (indicating that it may merit further consideration in the future). |
| 136: plain literal ranges and internationalisation | Accept | Accept | None | Postponed | As you point out, there are some constraints in the SKOS data model that we are unable to express in OWL (some of these /may/ be addressed by OWL 2, but in the current SKOS specification we are avoiding reference to work in progress). In such cases, the constraints are expressed in prose in the document. Thus the lack of an OWL version of S12 is rather through /necessity/ than intention. Statements to this effect are made in Section 1.7.1 of the LC draft. Do you feel these are sufficient, or do we need to further elaborate this point? As you point out, in this case it would be possible to approximate the constraint -- this is a choice we have not made here. |
| 137: property disjointness | Accept | Accept | None | Postponed | As you point out, there are some constraints in the SKOS data model that we are unable to express in OWL (some of these /may/ be addressed by OWL 2, but in the current SKOS specification we are avoiding reference to work in progress). In such cases, the constraints are expressed in prose in the document. Property disjointness is precisely one of these cases. Statements to this effect are made in Section 1.7.1 of the LC draft. Do you feel these are sufficient, or do we need to further elaborate this point? |
| 138: S14 skos:prefLabel | Accept | Accept | None | Postponed | As you point out, there are some constraints in the SKOS data model that we are unable to express in OWL (some of these /may/ be addressed by OWL 2, but in the current SKOS specification we are avoiding reference to work in progress). In such cases, the constraints are expressed in prose in the document. Statements to this effect are made in Section 1.7.1 of the LC draft. Do you feel these are sufficient, or do we need to further elaborate this point? |
| 139: example 16 | Accept | Accept | Editorial | Closed | The comment regarding the incompatability has been removed |
| 140: notations | Accept | Accept | Editorial | Closed | We propose to make an editorial change to the SKOS Reference, adding a note in section 6 explaining that no domain is stated for skos:notation. Would this be acceptable? |
| 141: almost-duplicate examples | Accept | Accept | None | Closed | We realise that, for those with experience of logics and entailment, such example may appear trivial and redundant. However, many readers of the SKOS Reference will not have extensive experience of logical entailment, and hence we have included these almost-duplicate examples to provide a clear illustration of the simple entailments that follow from the SKOS data model for these readers. We propose to retain these examples, can you live with this? |
| 142: | Accept | Accept | Editorial | Closed | This is potentially misleading and the titles of the sections have been changed accordingly. |
| 143: example 47 | Accept | Accept | Editorial | Closed | An explanation has been included along the lines you suggest. |
| 144: S44. S45 | Accept | None | Editorial | Closed | Following your suggestion, we propose to combine S44 and S45 into a single entry. |
| 145: property chains | Accept | None | Editorial | Closed | We propose to amend the SKOS Reference with wording following your suggestion. |
| 146: broadMatch and skos:narrowMatch should be used only when there are no exact or close matches for the term elsewhere? | Accept | Accept | None | Closed | Questions of best practice such as this are deemed out of scope for the SKOS Reference. We hope that answers to questions such as this will emerge in the future within the community of practice, in response to implementation experience. We propose to make no change to the SKOS Reference, can you live with this? ... We believe the SKOS Reference makes no judgment as to the relative importance of the different types of relationship. Can you live with the document as-is? |
| 147: Notations as plain literals | Accept | Accept | None | Closed | The design pattern that you propose is consistent with the SKOS data model and could be used to address the issue of notations. We welcome discussion of such patterns within the SKOS community, but at this point propose to make no changes to the current document. |
| 148: Irreflexive and noncyclical hierarchies | Accept | Accept | None | Closed | With SKOS (as with any vocabulary) the WG had to make decisions as to "when to stop" in terms of providing standardised vocabulary. As discussed in the SKOS Primer [2], custom extensions may be defined. In this case, we have decided to leave this as an exercise for the community and propose to *close* this issue, making no change at this point. |
| 149: Asymmetric associations | Accept | Accept | None | Postponed | While we are sympathetic to these requirements, at the current time we propose to postpone development of a standard solution and leave it for future working groups or for third party extensions developed within the community of practice. Both the SKOS Reference (section 8.6.3) and the SKOS Primer (section 4.7) currently provide examples of how to develop third party extensions to SKOS semantic relations. Can you live with this? |
| 150: Subsumption hierarchies | Accept | Accept | None | Postponed | Yes, the working group has considered carrying forward the experimental extensions to skos:broader and skos:narrower. This was discussed as ISSUE-56. In May the WG resolved to postpone this issue [2], because we do not yet have sufficient information on how to embed the specialisations in the current SKOS model. The view was that further work, in particular on patterns and conventions for using SKOS and OWL in combination, was required before a standard set of extensions could be proposed. We encourage the development and publication of third-party extensions to the SKOS data model within the community of practice. The SKOS Reference (section 8.6.3) and the SKOS Primer (section 4.7) provide information and examples of how to do this. |
| 151: skos:member definition | Accept | Accept | Editorial | Closed | We propose to state the range of skos:member as the union of skos:Concept and skos:Collection. We hope this will clarify the intended use of the SKOS collections framework. Is this acceptable? We have not encountered a requirement for an inverse of skos:member. We propose to make no change, can you live with this? |
| 152: Prefix for extension labels | Accept | None | Editorial | Closed | The Last Call Working Draft of the SKOS Reference [2] has adopted your suggestion, using "skosxl" as the conventional prefix for the SKOS XL namespace. |
| 153: SKOS namespace change question | Accept | None | Editorial | Closed | This was an issue that has been debated at length in the WG (see for example [2,3]) and the WG have seen merit in both options. The Last Call Draft proposes a new namespace. Recent discussions [4] have seen the WG return to a position where the SKOS vocabulary would be defined using the existing namespace URI. We do not intend to change the property names of the key semantic relations skos:broader and skos:narrower, as it was felt that this would effectively negate any benefit from retaining the namespace. This will, however, result in a change to the semantics of these relationships. However, as highlighted in [5], in principle applications should be able to make use of the machine-readable published schema. There may be impact on previously published vocabularies, which users will need to be made aware of. Note also that "old" vocabulary (for example skos:subject) will no longer be defined in the skos namespace. Historical versions of the schema will, however still be made available (although not at the SKOS namespace URI). Our proposal is thus to revert to the original SKOS namespace URI, and to add an appendix to the reference document (see [6]) discussing the issues above. |
| 154: Formality in SKOS Reference | Accept | Accept | Editorial | Closed | The outdated reference was an oversight that has now been rectified. A pointer to the RDF schema has been added to the introduction to the document, along with an explicit statement that the RDF/XML document is a normative subset of the specification. The Working Group propose to close this issue. |
| 155: SKOS in OWL 2 | Accept | Accept | None | Postponed | We note your comments that changes to the Recommendation at this point are not warranted. We do agree, however, that an OWL 2 version of SKOS would be useful, and would be happy to collaborate in producing a descriptive note along the lines suggested. As a consequence, we propose to *postpone* this issue. |
| 156: SKOS Notations and Datatypes | Accept | None | None | Closed | With respect to your comment regarding extra datatypes, the OWL Ontology reference document [3] states: [[ Tools may vary in terms of support for datatype reasoning. As a minimum, tools must support datatype reasoning for the XML Schema datatypes xsd:string and xsd:integer. OWL Full tools must also support rdf:XMLLiteral. For unsupported datatypes, lexically identical literals should be considered equal, whereas lexically different literals would not be known to be either equal or unequal. Unrecognized datatypes should be treated in the same way as unsupported datatypes. ]] Thus we would not expect applications to *reject* SKOS documents containing unsupported datatypes. The Working Group propose to make no change to the document in response to this comment and close this issue. |
| 157: SKOS and OWL 2 analysis | Accept | Accept | Editorial | Closed | [[ The OWL WG notes that some parts of the SKOS specification and some examples in the reference document do not fit within OWL 2 DL and that thus may not be fully supported by Semantic Web tools. The OWL WG presents the following analysis of the SKOS specification and examples, to indicate where representation capabilities beyond OWL 1 DL are used. The OWL WG further notes that in many cases the SKOS specification fits within OWL 2 DL, but that the examples do not. The OWL WG suggests removing those examples that do not fit within OWL 2 DL.([from [1]) ]] below you find our responses to the SKOS aspects that are not OWL 2 DL compliant. As a general strategy, we have tried as much as possible to accommodate the alignment with OWL 2 DL. A number of specific points cannot be resolved at this time (see below), so we have decided to POSTPONE this issue. [[ Section: Lexical Labels Language: OWL 2 Full Issue: subproperty of rdfs:label Suggestion: don't use rdfs:label ]] We prefer to keep the subProperty relation; however, we propose to change the type of the lexical label to owl:AnnotationProperty (see resolution of ISSUE 135 [3]). Assuming that OWL 2 DL will support subproperty statements between annotation properties, this change should at least partially solve the issue. [[ Section: Lexical Labels Language: OWL 2 Full Issue: objects as values of data property (example) Suggestion: don't do this ]] We assume you refer to example 17; we propose to remove this example. [[ Section: Documentation Language: OWL 2 Full Issue: using literal in object property (examples) Suggestion: don't do this Section: Documentation Language: OWL 2 Full Issue: use of rdf:value (example) Suggestion: don't use rdf:value ]] As discussed above, the resolution to ISSUE 135 [3] resulted in the SKOS labelling properties being typed as OWL Annotation properties. We propose that the documentation properties be treated similarly. This would then address the issue of the use of a literal with a documentation property. Although this is not then strictly OWL DL compliant, we understand that this will potentially fit with OWL 2 annotations. We propose to remove example 25 (the use of rdf:value). [[ Section: Lexical Labels Language: not OWL Issue: axiom schema for unique prefLabel Suggestion: include qualified cardinality restrictions only for languages used (defined using datatype restrictions) Section: Concept Collections Language: OWL 2 Full Issue: ordering with typing Suggestion: see [1] Section: SKOS XL Language: OWL 2 Full Issue: data property chains Suggestion: ?? ]] We assume these three issues refer to constraints S14 (lexical labels), S35 (ordered collections) and S56, S57 & S58 (SKOS XL). Indeed, these constraints can (currently) not be expressed in OWL. However, these are useful constraints for tool developers and we therefore prefer to keep these in the SKOS Reference. |
| 158: Turtle Notation | Accept | Accept | Editorial | Closed | The Turtle document is cited and referenced in Section 1.2. There are also brief explanations in Sections 1.7.3 and 9.5. Additional text has also been added to the end of Section 1.7. The Working Group propose to close this issue. I hope this is satisfactory |
| 160: Allowing collections in semantic relationships | Accept | Accept | None | Closed | The requirement to indicate that some concepts are not intended for use in indexing was raised in the SKOS Use Cases and Requirements document. Meeting this requirement was then discussed as ISSUE-46. The working group resolved to close this requirement because all matters related to indexing were deemed out of scope for SKOS, and better treated by vocabularies such as Dublin Core [3] or other third party vocabularies. We propose to make no change to the SKOS Reference. |
| 161: Argument on KOS purposes in SKOS Reference | Accept | Accept | Editorial | Closed | We agree with your observation and have inserted the following paragraph into Section 1.3. [[ In addition, some KOS are, by design, not intended to represent a logical view of their domain. Converting such KOS to a formal logic- based representation may, in practice, involve changes which result in a representation that no longer meets the intended purpose. ]] |
| 162: SKOS specialisation in SKOS Reference | Accept | None | None | Closed | There are some examples of specialising (extending) the SKOS data model in the SKOS Reference. For example, section 8.6.3. illustrates the refinement of the skos:related property. For example, section A.4.4.1. illustrates the refinement of the skosxl:labelRelation property. However, a detailed treatment of extending the SKOS data model was deemed out of scope for the SKOS Reference, and better treated in the SKOS Primer. We propose to make no change to the SKOS Reference, can you live with this? |
| 165: Reference to RDF Concepts | Accept | Accept | Editorial | Closed | The suggested reference has been added and the Working Group propose to close this issue. |
| 166: Turtle Notation II | Accept | Accept | Editorial | Closed | The suggested change has been made and the Working Group propose to close this issue. |
| 167: Application Behaviour re. Top Concepts | Accept | Accept | Editorial | Closed | This is the intent and we have clarified as suggested. |
| 168: Language Tags | Accept | Accept | Editorial | Closed | We have made the substitution and change as suggested. |
| 169: BCP Reference | Accept | Accept | Editorial | Closed | This reference has been fixed and the Working Group propose to close this issue |
| 170: Language Tags II | Accept | Accept | Editorial | Closed | This is indeed the intention -- your suggestion clarifies the position and we have made the change. |
| 171: Range of skos:member | Accept | None | Editorial | Closed | A similar comment was also raised regarding the range of skos:member (see ISSUE-151). To clarify the intended usage of the SKOS collections framework, we propose to state that the range of skos:member is the union of skos:Concept and skos:Collection. |
| 172: Well Formed Lists | Accept | None | Editorial | Closed | We propose to make an editorial change to section 9.6.2., adding the following below example 46: """ However, as stated in [RDF-SEMANTICS] section 3.3.3, semantic extensions to RDF may place extra syntactic well-formedness restrictions on the use of the RDF collection vocabulary (rdf:first, rdf:rest, rdf:nil) in order to rule out such graphs. """ |
| 173: Section 9.6.4 | Withdrawn | None | None | Closed | -- |
| 174: Cycles and skos:closeMatch | Accept | Accept | Editorial | Closed | Text as suggested has been included. We have, however, made no other substantial change to the document in response to your comment. The Working Group propose to close this issue. |
| 175: SKOS namespace change question II | Accept | None | Editorial | Closed | This was an issue that has been debated at length in the WG (see for example [2,3]) and the WG have seen merit in both options. The Last Call Draft proposes a new namespace. Recent discussions [4] have seen the WG return to a position where the SKOS vocabulary would be defined using the existing namespace URI. We do not intend to change the property names of the key semantic relations skos:broader and skos:narrower, as it was felt that this would effectively negate any benefit from retaining the namespace. This will, however, result in a change to the semantics of these relationships. However, as highlighted in [5], in principle applications should be able to make use of the machine-readable published schema. There may be impact on previously published vocabularies, which users will need to be made aware of. Note also that "old" vocabulary (for example skos:subject) will no longer be defined in the skos namespace. Historical versions of the schema will, however still be made available (although not at the SKOS namespace URI). Our proposal is thus to revert to the original SKOS namespace URI, and to add an appendix to the reference document (see [6]) discussing the issues above. |
| 176: Mapping vocabulary constraints | Accept | None | None | Postponed | The intended reading of this statement is not that axioms have been left unstated due to them requiring OWL 2 features, rather that the WG felt unable to make a clear decision as to whether such axioms should be stated /in any form/ (for example as prose). We propose to *postpone* this issue, with no change to the document. Is this acceptable? |
| 177: Labelling Normative Material | Accept | None | None | Closed | We are pleased to note your comments regarding the quality of the overall writing of the document. We believe that the distinction between normative and informative material is sufficient in the document in its current form. We also note that no other comments have been received on this point, and conclude that others in the community do not see problems in the lack of "sledgehammmer" labelling. As a result, we propose to *close* this issue with no change in response to your comment. |
| 178: PFWG: Semantic Relations | Accept | None | None | Postponed | The working group has considered including such extensions to skos:broader and skos:narrower within the SKOS data model. This was discussed as ISSUE-56. In May the WG resolved to postpone this issue [2], because we do not yet have sufficient information on how to embed the specialisations in the current SKOS model. The view was that further work, in particular on patterns and conventions for using SKOS and OWL in combination, was required before a standard set of extensions could be proposed. We encourage the development and publication of third-party extensions to the SKOS data model within the community of practice. The SKOS Reference (section 8.6.3) and the SKOS Primer (section 4.7) provide information and examples of how to do this. |
| 179: PFWG: Lexical Labels | Accept | None | None | Closed | The desire to provide a single value of preferred label is motivated by requirement R-CompatibilityWithISO2788 [2] and thesaurus guidelines provided the main motivation for the uniqueness of prefLabels. We also suggest that the intuitive interpretation of "preferred" implies a single choice. Note that the integrity conditions specify "no more than one preferred label per language [tag]", thus custom language tags /could/ be used in situations where competing preferred labels were needed. Note also that the presence of multiple preferred labels does not necessarily lead to *failure* of a SKOS application. Section 1.4 of the Reference document provides further discussion relating to the use of integrity conditions in SKOS. |
| 180: PFWG: skosxl:Label class | Accept | None | None | Postponed | We recognise these are important requirements, and would like to do all we can to help develop common solutions. We have considered expanding the scope of the current work to include standardised support for labels in other modalities (see e.g. [ISSUE-76]), however we have to balance the time this would take against the benefit to the community of having a more limited SKOS standard sooner. We are, however, committed to ensuring that SKOS is a sound basis for 3rd party extensions, to meet a diversity of more specialised requirements. We believe the XL framework, as currently specified, can serve as a basis for extensions that support labeling in a variety of modalities, and extensions that support a variety of label relationships, and would be happy to provide support and suggestions to the PFWG in the development of such extensions. We therefore propose to postpone this issue, making no change to the current specification. Are you able to live with this? |
| 181: Non Assignable Concepts | Accept | None | None | Closed | If I understand it correctly, your issue is that instances of skos:Collection cannot be included in hierarchies. Otherwise you could have represented your "centered entities" as collections. As you noted, we clearly distinguish the two "groupings" and "semantic networks" notions [6], and your "centered entities" cannot be modelled as Collections. Also, your "non-assignable concepts" heading hints that another solution would be possible, had we proposed a solution to the requirement R-IndexingAndNonIndexingConcepts [2]. Indeed, I guess your "non-assignable" concepts can be likened to what we called "non-indexing concepts". But R-IndexingAndNonIndexingConcepts has been dropped [4], as the indexing property requirement ISSUE-48 [3] (see note (1)). As a consequence of these problems having beeing already being extensively discussed, we propose to *close* ISSUE-181 [ISSUE-181], making no change to the existing SKOS documents. *We hope that you are able to live with this.* |
| 182: Index Terms | Accept | None | None | Closed | SKOS does not indeed offer by default an exact solution to your problem. Our concern with this issue is that its scope might be limited, considering the general context of KOS practice. We have not identified that kind of situation in our Use Cases and Requirements document [2], even for the (UDC) classification case we had [3]. We consequently propose to *close* ISSUE-182 [ISSUE-182], making no change to the existing SKOS documents. *We hope that you are able to live with this.* |
| 183: Class-Topic relationships | Accept | None | None | Closed | SKOS does not indeed offer by default an exact solution to your problem. Our concern with this issue is that its scope might be limited, considering the general context of KOS practice. We have not identified that kind of situation in our Use Cases and Requirements document [2], even for the (UDC) classification case we had [3]. Further, your problem is quite difficult to get. I assume that "subject/topics", even if they are different from classes, are still of conceptual nature -- they indeed play a structuring role in your KOS. They can therefore be modelled as instances of skos:Concept in their own right. Consequently, you could model all your semantic relations as standard SKOS relations, at the level of topic/subjects, or between classes and subjects/topics, without having to represent them at the class level. And thus avoid the cycles you mention. In the light of the assumed relative rarity of your case and existence of a potential solution for it, we propose to *close* ISSUE-183 [ISSUE-183], making no change to the existing SKOS documents. *We hope that you are able to live with this.* |
| 184: Notation and prefLabel overlap | Accept | None | None | Closed | Regarding your first comment, we would like to emphasize that you are free to use both skos:notation and the "private language tag" solutions and as you see fit. In particular, you can also use only one of them, for example if you do not want to coin a datatype of your own to be used with skos:notation. Assuming that the "preferred" aspect of a notation is what you really want to emphasize on, you can thus use skos:prefLabel only or skos:prefLabel and skos:notation, as you propose. Regarding the second aspect, nothing prevents the use skos:altLabel, in combination with private use tags, to express that a notation has an "alternative" flavour. Further, in SKOS the semantic relationships are attached to concepts and not to their lexicalizations, whether preferred or alternative. Your Q89/X17 example could be represented as: ex:x17 rdf:type skos:Concept ; skos:broader ex:x1 ; skos:prefLabel "environmental biology"@en ; skos:prefLabel "x17"@x-notation-mynotation ; skos:altLabel "q85"@x-notation-mynotation ; (assuming that your "X17" has "X1" as a parent class) There is no essential difference, as far as semantic relations are concerned, between representing notations as alternative or preferred labels. I hope this addresses your concerns appropriately. As we believe that the current SKOS model satisfies the requirements you mentioned, we propose to *close* ISSUE-184 [ISSUE-184], making no change to the existing SKOS documents. *We hope that you are able to live with this.* |
| 185: Order in Classification Systems | Accept | None | None | Closed | Indeed SKOS does not offer by default a solution to your problem. Usual RDF statements are order-neutral, and only RDF lists can be used to represent ordered groups. In fact we think it would be counter-productive for us to search and propose a solution at the level of property representation (something like "the first subclass of this class is X"). Further, such a use case was not clearly identified in the SKOS Use Case and Requirements [2]. Here, standardization concerns (see note (1)) dictate our not offering a specific solution . Consequently, we propose to *close* ISSUE-185 [ISSUE-185], making no change to the existing SKOS documents. *We hope that you are able to live with this.* |
| 186: Mappings | Accept | None | None | Closed | The current design for SKOS is based on a perceived consensus for mapping between vocabularies, which is to ground the different types of mapping relationship in the notions of hierarchical and associative relationships, and we believe that this consensus is consistent with existing standards. SKOS mapping relations cannot solve the heterogeneity of vocabularies and it is not possible to prevent wrong usage of the mapping relations. However, we think that the mapping relations do provide an important mechanism. Also, people can use, next to the broader/narrower, other mapping relations such as closeMatch and relatedMatch, which might be more suitable in heterogeneous cases. We agree that extending the mapping properties might very well be a good idea, but we prefer to leave this to developers. See also the section in the SKOS primer on extension mechanisms. |
| 187: skos:mappingRelation and skos:semanticRelation | Accept | None | Editorial | Closed | We agree with your suggestion and propose to add a statement to the SKOS data model such that skos:mappingRelation is a sub-property of skos:semanticRelation. |
| 190: Unicity of prefLabel (comment in SKOS RDF) | Accept | None | Editorial | Closed | We propose to change the SKOS RDF as per the commenter's suggestion. |
| 191: reference filtering in RFC 4647 | ?? |