Closed FranckCo closed 5 years ago
Keeping this issue open, assigning it to version 2 milestone.
+1 on "I'd have thought 'Alignment' to be better name for the role currently played by xkos:Correspondance' and 'correspondence' to be rather for xkos:ConceptAssociation"
Besides "Association" sounds like a too generic term (skos:broader also "associates" concepts)
In Knowledge Organization the current xkos:ConceptAssociation
is also known as concordance (see this paper). This word should at least be mentioned in the documentation. The more popular name, however, seems to be alignment like in ontology alignment. The name xkos:SchemeAlignment
might even be more clear.
For the parts of an alignment we use the term "mapping" but "association" (or the current xkos:ConceptAssociation
) is also fine. I think "correspondence" has a more specific meaning so better avoid it.
[We](https://coli-conc.gbv.de/> have specified a JSON-LD format for SKOS with extension for alignments/concordances and associations/mappings, see https://gbv.github.io/jskos/jskos.html#concordances. Compared to the current version of xkos the following is worth to consider (in short I agree with Isaac):
The concept schemes that take part in an alignment/concordance should have a direction, e.g. sourceScheme
and targetScheme
instead of compares
.
An association/mapping can involve multiple concepts combined by AND, OR and as ordered list. See https://gbv.github.io/jskos/jskos.html#concept-bundles and http://www.loc.gov/mads/rdf/v1#componentList. The latter is used in practice not only by us so please don't invent something new. I am not sure yet about AND (rdf:Set
?) and OR (rdf:Choice
?). The actual meaning of these different cases should be made clear:
maybe these three cases are already enough to differentiate AND, OR, and List but this needs to be defined and explained.
The naming of the classes and properties will not be modified in V1. The use-cases addressed by Correspondences in XKOS are described at the end of section 7. The primary goal is to map statistical classifications together; this implies that multiple sources / targets in a single ConceptAssociation are interpreted as a UNION.
The idea of having "sourceScheme" and "targetScheme" instead of simple "compares" is good and can be adressed in V2.
This is one of the comments made by Antoine Isaac (see issue #26):
xkos:Correspondence and xkos:ConceptAssociation. at the beginning it was unclear to me, but the example in 10.3 (really important for understanding!) convinced me this was a situation like ones in the ontology mapping community, where the EDOAL format uses an 'Alignment' class with 'Cells' for the individual correspondence. I reckon that the XKOS cases may be too far from the ontology matching ones, to your taste. Still, trying to stick as much as possible to existing terminology could be good. I'd have thought 'Alignment' to be better name for the role currently played by xkos:Correspondance' and 'correspondence' to be rather for xkos:ConceptAssociation.
Also, the choice that is currently made surprises me as one that is not very granular on the side of sourceConcept and targetConcept statements: concepts are individually attached to the Association instance. Isn't there a need to create 'bundles' with certain semantic flavor for both source and target of the association? I'd have thought the reification to happen rather at this level. The representation of one-to-many mappings 'AND', 'OR' mappings has been a long-standing problems in the SKOS community (http://www.w3.org/2006/07/SWD/track/issues/131). One of the basic patterns available is the combination/coordination of concepts, as done in the MADS vocabulary (see the use of madsrdf:componentList at http://www.loc.gov/standards/mads/rdf/#t22 to link a bundle of concepts to the list of its components). If XKOS has cases that needs them, it would be interesting if the old proposals for SKOS mappings (http://www.w3.org/2004/02/skos/mapping/spec/2004-11-11.html) could be revived!