Table of Contents

• The ddot.it Relation Names
• The CDS Vocabulary
  • Relations
    • Reading the labels
  • Item Types
  • Axiomatic Triples
• Inference Rules
  • r01 — transitive
  • r02 — inverse (A-box)
  • r03 — inverse (T-box) — not active
  • r04 — type inheritance
  • r05 — relation inheritance
  • r06 — alias in subject position
  • r07 — alias in predicate position
  • r08 — alias in object position
  • r09 — symmetric (A-box)
  • r10 — self-inverse implies symmetric
  • r11 — symmetric implies self-inverse
  • r12 — inverse of inverse is the same relation
  • r13 — inverse inherits type
  • r14 — sameAs in subject position
  • r15 — sameAs in predicate position
  • r16 — sameAs in object position
  • r17 — sub-type relation carries over to inverses
  • r18 — tags propagate to parts
  • Rule Sets
    • Cost Model
• Mapping the Two Vocabularies
• ECore Kernel
  • Cardinality
    • Writing Cardinality in ddot.it
  • Beyond Cardinality
• Mapping to Standard Vocabularies
  • RDFS
  • OWL
  • SKOS
  • WordNet
  • Summary
• Design Decisions

This document delivers background information about design decisions.

This document describes the relation vocabularies of ddot.it and the inference rules that come with them. It is the semantic layer that a ddot.it tool may apply on top of the plain triple stream produced by parsing (see the parsing spec). Nothing here affects the syntax: to the parser, all these relations are ordinary strings.

Two vocabularies are described:

The ddot.it Relation Names

The small set of common relation names suggested for everyday ddot.it use.

The CDS Vocabulary

CDS (Conceptual Data Structures), the full formal vocabulary with inverses, a relation hierarchy and inference rules.

The first is a human-facing subset; the second is what a reasoner works with. See Mapping the Two Vocabularies for how they relate.

ECore Kernel supplies the cardinality model, and Mapping to Standard Vocabularies aligns CDS with RDFS, OWL, SKOS and WordNet.

The ddot.it Relation Names

The ddot.it-facing relation names — related, links to, has type, has subtype, text, label and the rest — are not defined here. They are declared in the Vocabulary Specification, where each is a machine-readable built-in carrying its own has type, has supertype, has inverse, uri and has alias triples, checked against ddot-it-vocabulary.ddot by CI.

This document previously repeated those names in a hand-written table. The copy drifted from the declarations — listing has content as a relation of its own when it is an alias of text, and carrying aliases that were never declared — so it has been removed rather than re-synchronised. For the canonical name of any relation, and for its full set of aliases, read the vocabulary.

What remains here is the alignment material: the CDS vocabulary and its inference rules, the mapping between CDS and ddot.it, the ECore cardinality kernel, and the mappings to RDFS, OWL, SKOS and WordNet.

The CDS Vocabulary

CDS = Conceptual Data Structures.

Source of truth: de.xam.cds.CdsId (names, labels, inverses, transitivity), de.xam.cds.CdsIdT (axiomatic triples) and de.xam.cds.CdsRules (inference rules).

Background: "Personal Knowledge Models with Semantic Technologies", page 148 pp., available from xam.de/go/pkm.

Namespace: http://www.semanticdesktop.org/ontologies/2007/09/01/cds#

Relations

Each relation has a technical id, a human-readable label, an inverse relation and — except for the root — a super-relation. The T column marks transitive relations, the S column marks symmetric relations (a relation is symmetric exactly when it is its own inverse).

Id	Label	Inverse	Super-relation	T	S
Layer 0 — root
hasRelated	is related to	hasRelated	_(none, root)_		✓
Layer 1 — linking
hasSimilar	is similar to	hasSimilar	hasRelated		✓
hasTarget	links to	hasSource	hasRelated
hasSource	is linked from	hasTarget	hasRelated
Layer 2 — ordering, detail, annotation
hasAfter	comes before	hasBefore	hasTarget	✓
hasBefore	comes after	hasAfter	hasSource	✓
hasDetail	has detail	hasContext	hasTarget
hasContext	has context	hasDetail	hasSource
hasAnnotationMember	annotates	hasAnnotation	hasTarget
hasAnnotation	has annotation	hasAnnotationMember	hasSource
Layer 3 — tagging
hasTagMember	is tag of	hasTag	hasAnnotationMember
hasTag	is tagged with	hasTagMember	hasAnnotation
Layer 4 — typing
hasInstance	has instance	hasType	hasTagMember
hasType	has type	hasInstance	hasTag
Part-of and type hierarchy
hasPart	has part	isPartOf	hasDetail	✓
isPartOf	is part of	hasPart	hasContext	✓
hasSubType	has subtype	hasSuperType	hasDetail	✓
hasSuperType	is subtype of	hasSubType	hasContext	✓
Identity and aliasing
sameAs	is same as	sameAs	hasSimilar	✓	✓
isAliasOf	is alias for	hasAlias	hasSimilar
hasAlias	has alias	isAliasOf	hasSimilar
replaces	replaces	replacedBy	hasSimilar
replacedBy	is replaced by	replaces	hasSimilar
Wiki / auto linking (added 2014-07-13)
hasAutoLinkTarget	auto-links to	hasAutoLinkSource	hasTarget
hasAutoLinkSource	auto-linked from	hasAutoLinkTarget	hasSource
hasManualLinkTarget	wiki-links to	hasManualLinkSource	hasTarget
hasManualLinkSource	wiki-linked from	hasManualLinkTarget	hasSource
CDS data model (the meta level)
hasInverse	has inverse	hasInverse	_(none)_		✓

The super-relation is asserted in the axioms only for one direction of each inverse pair (e.g. hasRelated hasSubType hasTarget). The super-relation of the inverse side is not asserted; it follows from r17 — sub-type relation carries over to inverses. The table lists it explicitly for readability.

Reading the labels

The label reads in subject-first direction: (x, hasAfter, y) is read as "x comes before y", and (x, hasSuperType, y) as "x is subtype of y". The id is written from the perspective of what the subject has; the label from the perspective of what the subject does. This is why some pairs look inverted at first glance.

Item Types

Three items — not relations — classify relations themselves:

Id	Label
type_relation	relation
type_symmetricRelation	symmetric relation
type_transitiveRelation	transitive relation

Both type_symmetricRelation and type_transitiveRelation are sub-types of type_relation.

Axiomatic Triples

For every relation pair (r, inv) with super-relation sup, these triples are asserted:

(r,   hasType,    type_relation)
(inv, hasType,    type_relation)
(r,   hasInverse, inv)
(sup, hasSubType, r)

Plus the relation-type assertions:

(hasAfter,      hasType, type_transitiveRelation)
(hasBefore,     hasType, type_transitiveRelation)
(sameAs,        hasType, type_transitiveRelation)
(hasSubType,    hasType, type_transitiveRelation)
(hasSuperType,  hasType, type_transitiveRelation)
(hasPart,       hasType, type_transitiveRelation)

(hasInverse,    hasType, type_symmetricRelation)
(sameAs,        hasType, type_symmetricRelation)
(hasRelated,    hasType, type_symmetricRelation)

(type_relation, hasSubType, type_symmetricRelation)
(type_relation, hasSubType, type_transitiveRelation)

Inference Rules

The rules are forward-chaining production rules over triples. ?x denotes a variable, quoted names denote fixed relations from Relations. Conditions are listed above the =⇒, the derived triple below.

r01 — transitive

Transitive closure for any relation declared transitive.

?x   ?p        ?y
?y   ?p        ?z
?p   'hasType' 'type_transitiveRelation'
  ==>
?x   ?p        ?z

r02 — inverse (A-box)

Every statement also holds in the inverse direction.

?x   ?p           ?y
?p   'hasInverse' ?q
  ==>
?y   ?q           ?x

r03 — inverse (T-box) — not active

hasInverse symmetry. This rule is configured but not registered with the engine: the axiomatic triple (hasInverse, hasType, type_symmetricRelation) combined with r09 — symmetric (A-box) achieves the same.

?p   'hasInverse' ?q
  ==>
?q   'hasInverse' ?p

r04 — type inheritance

An instance of a type is also an instance of that type’s super-types.

?x   'hasType'      ?t
?t   'hasSuperType' ?u
  ==>
?x   'hasType'      ?u

r05 — relation inheritance

A statement using a relation also holds for that relation’s super-relations.

?x   ?p              ?y
?p   'hasSuperType'  ?u
  ==>
?x   ?u              ?y

r05 — relation inheritance can trigger r01 — transitive, so the two must be registered together for a complete closure.

r06 — alias in subject position

?alias    'isAliasOf' ?resolved
?alias    ?p          ?o
  ==>
?resolved ?p          ?o

r07 — alias in predicate position

?alias    'isAliasOf' ?resolved
?s        ?alias      ?o
  ==>
?s        ?resolved   ?o

r08 — alias in object position

?alias    'isAliasOf' ?resolved
?s        ?p          ?alias
  ==>
?s        ?p          ?resolved

r09 — symmetric (A-box)

?x   ?p        ?y
?p   'hasType' 'type_symmetricRelation'
  ==>
?y   ?p        ?x

r10 — self-inverse implies symmetric

?p   'hasInverse' ?p
  ==>
?p   'hasType'    'type_symmetricRelation'

r11 — symmetric implies self-inverse

The converse of r10 — self-inverse implies symmetric; together they make the two formulations equivalent.

?p   'hasType'    'type_symmetricRelation'
  ==>
?p   'hasInverse' ?p

r12 — inverse of inverse is the same relation

?p   'hasInverse' ?q
?q   'hasInverse' ?r
  ==>
?p   'sameAs'     ?r

r13 — inverse inherits type

A relation and its inverse share all types (both transitive, both symmetric, …).

?p   'hasInverse' ?q
?p   'hasType'    ?t
  ==>
?q   'hasType'    ?t

r14 — sameAs in subject position

?a   'sameAs' ?b
?a   ?p       ?c
  ==>
?b   ?p       ?c

r15 — sameAs in predicate position

?p   'sameAs' ?r
?a   ?p       ?b
  ==>
?a   ?r       ?b

r16 — sameAs in object position

?b   'sameAs' ?c
?a   ?p       ?b
  ==>
?a   ?p       ?c

r17 — sub-type relation carries over to inverses

If a is a sub-relation of c, then the inverse of a is a sub-relation of the inverse of c. This is what gives the inverse-side relations in Relations their super-relation.

?a   'hasInverse'   ?b
?c   'hasInverse'   ?d
?a   'hasSuperType' ?c
  ==>
?b   'hasSuperType' ?d

r18 — tags propagate to parts

Added 2015-12-29. A tag on a whole applies to each of its parts.

?a    'hasTag'  ?tag
?a    'hasPart' ?part
  ==>
?part 'hasTag'  ?tag

Rule Sets

Rules are grouped so that an implementation can trade completeness for speed:

Group	Rules	Note
transitive	r01 — transitive	The expensive one — closure can blow up
inverse	r02 — inverse (A-box), r13 — inverse inherits type	r03 — inverse (T-box) — not active configured but not registered
symmetric	r09 — symmetric (A-box), r10 — self-inverse implies symmetric, r11 — symmetric implies self-inverse
alias	r06 — alias in subject position, r07 — alias in predicate position, r08 — alias in object position
sameAs	r12 — inverse of inverse is the same relation, r14 — sameAs in subject position, r15 — sameAs in predicate position, r16 — sameAs in object position	r12 — inverse of inverse is the same relation derives sameAs from inverse chains
type inheritance	r04 — type inheritance, r05 — relation inheritance, r17 — sub-type relation carries over to inverses
part	r18 — tags propagate to parts

Predefined configurations:

All

All of the above.

AllExceptTransitive

Everything but r01 — transitive. The common choice when the closure is too costly.

OnlyTransitive

r01 — transitive only.

None

No inference.

Cost Model

When a rule engine picks an evaluation order for the conditions of a rule, it counts unbound variables and adds a penalty per relation, reflecting how often that relation typically occurs:

Relation	Penalty	Frequency
hasSubType	0.2	rare
hasSuperType	0.2	rare
hasInverse	0.2	rare
sameAs	0.7	medium
hasAlias	0.8	medium
isAliasOf	0.8	medium
hasType	0.9	frequent
hasInstance	0.9	frequent
_all others_	0

The penalty applies only when the predicate itself is bound but subject or object are not.

Mapping the Two Vocabularies

Every relation declared in the Vocabulary Specification, and how it corresponds to CDS. Ddot.it uses the CDS labels rather than the CDS ids.

Table 1. Relations between things

ddot.it name	CDS id	Note
related	hasRelated	Symmetric root relation
has inverse	hasInverse	Symmetric; pairs a relation with its opposite
has similar	hasSimilar	Symmetric
same as	sameAs	Symmetric and transitive
is alias of	isAliasOf	Inverse hasAlias ("has alias")
replaces	replaces	Inverse replacedBy; transitive in ddot.it only, see Where ddot.it adds to CDS
links to	hasTarget	Inverse hasSource ("is linked from")
has next	hasAfter	Inverse hasBefore ("has previous"); transitive
has detail	hasDetail	Inverse hasContext ("has context")
has part	hasPart	Inverse isPartOf ("is part of"); transitive
has subtype	hasSubType	Inverse hasSuperType ("has supertype"); transitive
annotates	hasAnnotationMember	Inverse hasAnnotation ("has annotation")
is tag of	hasTagMember	Inverse hasTag ("has tag")
has instance	hasInstance	Inverse hasType ("has type")

Relations carrying a value

None of these has a CDS counterpart: CDS models values through its own data model rather than through a property hierarchy.

ddot.it name	CDS id	Note
has property	--	Root of the value-carrying family; the type is property
label	--	The visible name of a node
text	--	Free content; alias has content. Carries the ,, meta text
uri	--	Identifying relation
prefix	--	A parsing directive, not a semantic relation
source uri	--	Provenance
collected	--	Provenance
valid since	--	Provenance
valid until	--	Provenance
last modified	--	Provenance
grade	--	Replaces the four CDS auto/manual-link relations, see below

Coverage

Of the 28 relations in the CDS relation table, 24 have a ddot.it counterpart above — both directions of every inverse pair. The remaining four are deliberately not carried over:

CDS	Superseded by
hasAutoLinkTarget / hasAutoLinkSource	links to + ,, ..grade.. unreviewed
hasManualLinkTarget / hasManualLinkSource	links to + ,, ..grade.. manual

CDS encoded link provenance in the relation name; ddot.it encodes it as grade meta on an ordinary links to, which keeps the link itself one relation. The exact rewrite is tabulated in the vocabulary’s "Migration from CDS".

Differences to reconcile:

• ddot.it says tags are not transitive; CDS does not declare hasTag transitive either — consistent.

• ddot.it says a has subtype cycle collapses to same as; CDS has no rule for this. r12 — inverse of inverse is the same relation derives sameAs from inverse chains only.

Where ddot.it adds to CDS

replaces / is replaced by are declared transitive in the Vocabulary Specification, and in the generated ddot-it-vocabulary.ddot. CDS does not: neither replaces nor replacedBy appears in the transitive axiom list, and the CDS relation table above accordingly leaves their T column empty.

This is a deliberate ddot.it addition, not a transcription error. If a replaces b and b replaces c, then a replaces c is what a reader expects, and the inference is monotonic like every other. The CDS tables in this document describe CDS, so they are left unmarked; the divergence is recorded here instead of being hidden by editing either side.

has subtype cycles collapse to same as. If a has subtype b and b has subtype a, the vocabulary concludes a ..same as.. b — every participant of the cycle is one entity. CDS has no such rule: r12 — inverse of inverse is the same relation derives sameAs from chains of inverses only, and nothing in the CDS rule set closes a subtype cycle.

The addition is what keeps a cycle from being an error. In a monotonic language nothing can be rejected, so a subtype cycle has to mean something; reading it as identity is both the useful answer and the one that adds inferences rather than removing them.

By contrast, isPartOf is marked transitive in the CDS table above even though the axiom list names only hasPart. That is not an addition: r13 — inverse inherits type ("a relation and its inverse share all types") forces it, and CDS spells out both sides for the comparable hasSubType/hasSuperType pair. The unmarked isPartOf was an omission in the table.

ECore Kernel

Ecore is the meta-model of EMF. It is the closest well-established model to what ddot.it needs for cardinalities, so we borrow its kernel here.

Indentation is rdfs:subClassOf:

• ENamedElement ..hasName.. String

  • EClassifier

    • EClass

    • EDataType

  • ETypedElement ..hasEType.. an EClassifier

    • EStructuralFeature

      • EAttribute

      • EReference

Cardinality

Cardinality in Ecore is not a separate class. It is four attributes on ETypedElement, and therefore inherited by every EAttribute and EReference:

Attribute	Type	Default	Meaning
lowerBound	EInt	0	Minimum number of values. >= 1 means required.
upperBound	EInt	1	Maximum number of values. -1 means unbounded (*).
ordered	EBoolean	true	Whether the order of multiple values is meaningful.
unique	EBoolean	true	Whether duplicate values are forbidden.

Two further attributes are derived — they are not stored, they follow from the bounds:

Derived attribute	Definition
required	lowerBound >= 1
many	upperBound > 1 or upperBound == -1

The four combinations that cover almost all practical cases:

Notation	lowerBound	upperBound	Meaning
0..1	0	1	Optional single value
1..1	1	1	Exactly one — required single value
0..*	0	-1	Any number, including none
1..*	1	-1	At least one

ordered and unique only matter when many is true. With unique = true and ordered = false a multi-valued feature behaves like a set, with both true like an ordered set, with unique = false and ordered = true like a list.

Writing Cardinality in ddot.it

Ddot.it declares this model as built-ins — see Cardinality in the Vocabulary Specification. Bounds are written as two separate properties, each taking a plain integer:

Person ..has address.. Address ,, ..min cardinality.. 1 ;; ..max cardinality.. 3
Person ..has name.. String ,, ..cardinality.. 1

An omitted max cardinality means unbounded; there is no or -1 sentinel. The named shorthands required, single valued and multi valued cover the common cases as relation *types.

A range written as one value — 1..3 — is not used. It parses where it stands, since a meta object may contain .., but the same string reused as a subject silently misparses (1..3 ..has type.. cardinality reads as subject 1, relation 3). Two bounds avoid the collision entirely.

Table 2. Name mapping

ECore	ddot.it	Note
lowerBound	min cardinality	Declared alias lowerBound
upperBound	max cardinality	Declared alias upperBound; omit for unbounded
required	required	ECore derives it; ddot.it declares it as a relation type
many	multi valued	ECore derives it; in ddot.it it is the default, so it only documents intent
ordered	--	Not modelled: ddot.it triples have no inherent order
unique	--	Not modelled: a ddot.it triple base is a set, so duplicates do not arise

Beyond Cardinality

The remaining Ecore kernel attributes are listed here for completeness; ddot.it does not currently assign them a meaning.

Class	Attribute	Meaning
EClass	abstract	Cannot be instantiated directly
EClass	interface	Has no implementation
EStructuralFeature	changeable	May be modified after creation
EStructuralFeature	derived	Computed, not stored
EStructuralFeature	transient	Not serialised
EAttribute	iD	Serves as the identifier of its instances
EReference	containment	The target is owned by the source (composition)
EReference	eOpposite	The inverse reference — compare CDS hasInverse
EDataType	serializable	Values can be converted to and from a string

EReference.eOpposite and CDS hasInverse express the same idea, and EReference.containment overlaps with CDS hasPart. Those equivalences are recorded here, but the rest of the ECore kernel is not imported: ddot.it borrows ECore only as its cardinality model. The remaining attributes above are implementation concerns of a modelling framework (serialisation, mutability, abstractness) rather than statements about a knowledge graph, and they have no ddot.it counterpart.

Mapping to Standard Vocabularies

CDS was designed independently, but it overlaps heavily with the established semantic web vocabularies. This chapter lists the relations that actually get used in practice from each, and how they map.

The Fit column is used throughout:

=	Exact. Same meaning, same direction, same formal properties.
~	Close. Usable, but something is lost — direction, transitivity, or scope.
–	No CDS equivalent.

CDS has no negation and no notion of inconsistency. The rules in Inference Rules derive triples and nothing else — there is no way to write "not", and no outcome other than "here are more triples". Constructs such as owl:differentFrom, owl:disjointWith or WordNet’s antonym therefore have no CDS counterpart: they do their work by making a knowledge base unsatisfiable, which presupposes a reasoner that can detect and report a contradiction. Adding them to CDS means adding a consistency check, not just a relation.

This is not a monotonicity difference — RDFS, OWL and CDS are all monotonic. Adding statements never retracts an earlier conclusion in any of them.

RDFS

Namespaces: rdf: = http://www.w3.org/1999/02/22-rdf-syntax-ns#, rdfs: = http://www.w3.org/2000/01/rdf-schema#

RDFS is the smallest of the four and the closest to CDS in spirit — a handful of relations, a subclass hierarchy, and entailment rules that only add triples.

RDFS	Fit	CDS	Note
rdf:type	=	hasType	Same direction, same meaning.
rdfs:subClassOf	=	hasSuperType	X subClassOf Y = X hasSuperType Y. Both transitive.
rdfs:subPropertyOf	~	hasSuperType	CDS uses one hierarchy for items and relations alike; RDFS keeps class and property hierarchies apart.
rdfs:label	~	--	Maps to the ddot.it label relation, not to a CDS relation.
rdfs:comment	~	hasDetail	Or the ddot.it has content relation.
rdfs:seeAlso	=	hasTarget	The untyped directed link. ddot.it links to.
rdfs:isDefinedBy	~	hasContext	rdfs:subPropertyOf rdfs:seeAlso in RDFS; CDS has no equivalent narrowing.
rdfs:member	~	isPartOf	CDS hasPart is transitive, rdfs:member is not.
rdfs:domain	–	--	Constrains the subject of a property. See ECore Kernel.
rdfs:range	–	--	Constrains the object of a property. See ECore Kernel.
rdf:value	–	--	Structured-value idiom; the ddot.it ,, meta part covers this use case differently.
rdf:first, rdf:rest, rdf:nil	–	--	RDF list encoding. No CDS ordering primitive; CDS has hasAfter / hasBefore instead.

Classes rather than relations, listed for orientation: rdfs:Resource, rdfs:Class, rdf:Property, rdfs:Literal, rdfs:Datatype, rdfs:Container.

RDFS entailment rules rdfs9 (type inheritance) and rdfs7 (property inheritance) correspond exactly to CDS r04 — type inheritance and r05 — relation inheritance. rdfs5 and rdfs11 (transitivity of subPropertyOf / subClassOf) correspond to r01 — transitive applied to hasSuperType.

OWL

Namespace: owl: = http://www.w3.org/2002/07/owl#

OWL is where CDS finds its closest formal matches: hasInverse, sameAs, type_symmetricRelation and type_transitiveRelation are all direct OWL analogues. It is also where CDS stops — OWL’s class constructors and negation have no counterpart.

OWL	Fit	CDS	Note
owl:inverseOf	=	hasInverse	Direct match. Compare r02 — inverse (A-box).
owl:sameAs	=	sameAs	Direct match. Compare r14 — sameAs in subject position–r16 — sameAs in object position.
owl:SymmetricProperty	=	type_symmetricRelation	Direct match. Compare r09 — symmetric (A-box).
owl:TransitiveProperty	=	type_transitiveRelation	Direct match. Compare r01 — transitive.
owl:equivalentClass	~	sameAs	CDS does not separate class-level from individual-level identity.
owl:equivalentProperty	~	sameAs	CDS derives this via r12 — inverse of inverse is the same relation.
owl:topObjectProperty	=	hasRelated	The root of the relation hierarchy.
owl:ObjectProperty	~	type_relation	Compare Ecore EReference.
owl:DatatypeProperty	~	--	Compare Ecore EAttribute.
owl:FunctionalProperty	~	--	Ecore upperBound = 1. See Cardinality.
owl:InverseFunctionalProperty	~	--	Ecore EAttribute.iD.
owl:minCardinality	~	--	Ecore lowerBound.
owl:maxCardinality	~	--	Ecore upperBound.
owl:differentFrom	–	--	Negative. Not expressible in CDS.
owl:disjointWith	–	--	Negative. Not expressible in CDS.
owl:complementOf	–	--	Negative. Not expressible in CDS.
owl:unionOf, owl:intersectionOf	–	--	Class constructors. CDS has no anonymous classes.
owl:Restriction, owl:onProperty, owl:someValuesFrom, owl:allValuesFrom	–	--	Property restrictions. CDS has no anonymous classes.
owl:imports	–	--	Document-level, not statement-level.
owl:deprecated	~	replacedBy	Only when a successor is named.

CDS is roughly at the expressiveness of OWL RL minus the negative constructs — property hierarchies, inverses, symmetry, transitivity and identity, all as forward-chaining rules that only ever add triples.

SKOS

Namespace: skos: = http://www.w3.org/2004/02/skos/core#

SKOS models concept schemes — thesauri, taxonomies, subject headings — rather than logical classes. Because it is deliberately informal about what a hierarchy means, it sits closer to everyday ddot.it usage than OWL does.

SKOS	Fit	CDS	Note
skos:related	=	hasRelated	Symmetric, non-transitive. The best match in the whole chapter.
skos:closeMatch	=	hasSimilar	Symmetric. Direct match.
skos:exactMatch	=	sameAs	Transitive and symmetric in both vocabularies.
skos:broaderTransitive	=	hasSuperType	Transitive in both.
skos:narrowerTransitive	=	hasSubType	Transitive in both.
skos:broader	~	hasSuperType	Mismatch: skos:broader is deliberately not transitive; CDS hasSuperType is.
skos:narrower	~	hasSubType	Same mismatch, mirrored.
skos:prefLabel	~	--	The ddot.it label relation.
skos:altLabel	~	hasAlias	CDS aliasing also rewrites triples (r06 — alias in subject position–r08 — alias in object position); SKOS labels do not.
skos:hiddenLabel	–	--	Search-only label. No CDS concept.
skos:definition	~	hasDetail	Or ddot.it has content.
skos:note, skos:scopeNote, skos:editorialNote	~	hasAnnotation	The CDS annotation layer.
skos:example	~	hasInstance	Informal in SKOS, formal in CDS.
skos:member	~	hasPart	For skos:Collection. CDS hasPart is transitive.
skos:inScheme	~	hasTag	Membership in a concept scheme.
skos:hasTopConcept	~	hasPart	Entry point of a scheme.
skos:notation	–	--	A code in a notation system.
skos:broadMatch, skos:narrowMatch, skos:relatedMatch	~	hasSuperType, hasSubType, hasRelated	Cross-scheme variants of the corresponding intra-scheme relations. CDS does not distinguish.

The skos:broader transitivity mismatch is the one to watch when importing a thesaurus. SKOS separates broader from broaderTransitive precisely so that hierarchies with mixed part-of / kind-of steps do not produce nonsense conclusions. Importing skos:broader as CDS hasSuperType re-enables exactly the inference SKOS was avoiding. Map to hasDetail / hasContext instead when this matters.

WordNet

Namespace (W3C 2006 conversion): wn: = http://www.w3.org/2006/03/wn/wn20/schema/. See also the Global WordNet schemas.

WordNet is a lexical database: its nodes are word senses grouped into synsets, not concepts. The mapping is therefore approximate throughout — a WordNet relation holds between meanings of words, a CDS relation between things.

Direction convention

A WordNet row names a pointer, and a pointer is read from the synset that carries it to the synset it names. The CDS column gives the relation holding in that same direction, so the carrier of the pointer is always the CDS subject.

This matters most for the part/whole pairs, where the names invite the opposite reading: a holonym pointer runs from the part to the whole (tree --member holonym-→ forest), so its subject is the part and it maps to isPartOf. A meronym pointer runs from the whole to the part, and maps to hasPart. The prose notes below read in the same direction.

WordNet	Fit	CDS	Note
hypernym	=	hasSuperType	"is a kind of". Transitive in both.
hyponym	=	hasSubType	Inverse of hypernym.
instance hypernym	=	hasType	For named individuals — Berlin is an instance of city.
instance hyponym	=	hasInstance	Inverse of the above.
member holonym	~	isPartOf	tree is a member of forest.
member meronym	~	hasPart	Inverse.
part holonym	~	isPartOf	branch is a part of tree.
part meronym	~	hasPart	Inverse.
substance holonym	~	isPartOf	wood is the substance of tree.
substance meronym	~	hasPart	Inverse.
similar to	=	hasSimilar	Adjective satellites. Symmetric in both.
also see	=	hasTarget	The untyped "see also" link.
derivationally related form	~	hasRelated	Symmetric in both. decide / decision.
domain — topic	~	hasTag	The subject field of a synset. A good hasTag fit.
member of domain — topic	~	hasTagMember	Inverse.
synset membership	~	sameAs	Words in one synset share a meaning. Lossy: synonymy is context-dependent, sameAs is absolute.
gloss / definition	~	hasDetail	Or ddot.it has content.
lemma / word form	~	--	The ddot.it label relation.
antonym	–	--	Negative. Not expressible in CDS.
entailment	–	--	snore entails sleep. Verb-specific.
cause	–	--	kill causes die. Verb-specific.
verb group	–	--	Groups related verb senses.
attribute	–	--	Links a noun to a descriptive adjective.
pertainym	–	--	dental pertains to tooth.

The synset membership → sameAs mapping is the dangerous one. CDS sameAs is transitive and symmetric and rewrites triples through r14 — sameAs in subject position–r16 — sameAs in object position, so importing synonymy as sameAs will merge word senses that WordNet keeps carefully apart. Prefer hasSimilar, which is symmetric but not transitive and triggers no rewriting.

Summary

The relations that map exactly across all four:

CDS	Corresponds to
hasType	rdf:type, WordNet instance hypernym
hasSuperType	rdfs:subClassOf, skos:broaderTransitive, WordNet hypernym
hasInverse	owl:inverseOf
sameAs	owl:sameAs, skos:exactMatch
hasRelated	skos:related, owl:topObjectProperty
hasSimilar	skos:closeMatch, WordNet similar to
hasTarget	rdfs:seeAlso, WordNet also see
type_symmetricRelation	owl:SymmetricProperty
type_transitiveRelation	owl:TransitiveProperty

What CDS has that the others lack: a single unified hierarchy for items and relations, and the alias mechanism (r06 — alias in subject position–r08 — alias in object position), which rewrites triples rather than merely asserting equivalence.

What CDS lacks: negation of any kind, cardinality (borrowed from ECore Kernel), domain and range constraints, and anonymous classes.

Design Decisions

Settled

Which CDS relations belong to the ddot.it core. All of them that have a counterpart: the mapping tables list every relation the Vocabulary Specification declares, and Coverage records that 24 of the 28 CDS relations map directly while the four link-provenance relations are superseded by grade. Anything in the CDS relation table that does not appear in the mapping is CDS-only and not part of ddot.it.

Surface form. Ddot.it writes the vocabulary’s own names — has subtype, links to, same as — not CDS ids and not CDS labels. Those names, and their aliases, are declared as built-ins and checked by CI. This side-steps the label/id direction hazard entirely: a ddot.it name means what the vocabulary declares, and the CDS id is given alongside it in the mapping tables for anyone reading CDS sources.

Cardinality. Settled in the Vocabulary Specification: two integer bounds (min cardinality / max cardinality), an omitted maximum meaning unbounded, cardinality as the equal-bounds shorthand, and required / single valued / multi valued as relation types. ordered and unique are out of scope — see the name mapping in Writing Cardinality in ddot.it for why.

Still open

Status of the alignment tables. The mappings in Mapping to Standard Vocabularies are descriptive, with one normative core.

Spec

A ddot.it RDF importer or exporter MUST implement the mappings marked = (an exact fit): rdf:type, rdfs:subClassOf, owl:inverseOf and owl:sameAs among them. These are round-trippable in both directions and are what makes two independent exporters agree.

Every mapping marked ~ (an approximation) is advisory. A tool MAY implement it and SHOULD document that it does. The approximations carry real hazards — skos:broader is not transitive while CDS hasSubType is, and WordNet synonymy is not owl:sameAs — which is exactly why they are not required.

hasInstance has hasTagMember as its super-relation, which places typing below tagging in the CDS hierarchy. This is intentional: Fig. 4.5 of the source thesis (Personal Knowledge Models with Semantic Technologies, p. 122) shows has instance as a sub-relation of is tag of, so that a hasType b implies a hasTag b and type- and tag-browsing share one user interface.