Jeremy:
> _:a owl:equivalentClass _:b .
> _:c owl:equivalentClass _:d .
>
> (over four distinct bnodes, rather than three distinct
> bnodes in the original).
Peter:
> The two versions entail each other, but are
> different syntactically.
which is the essence of my various suggested fixes -
force the concrete syntax only to talk about pairs
of descriptions
and these are semantically equivalent to abstract syntax
n-tuples of descriptions
Possibilities include:
A: restrict abstract syntax to pairs in EquivalentClasses
and DisjointClasses
B: only allow for mapping pairs of EquivalentClasses or
DisjointClasses (n-tuples allowed in abstract syntax but
have no mapping under the mapping rules)
C: Use a variant of the n-tuple mapping rule that maps
an n-tuple into n or n(n-1)/2 pairs, and then map them
i.e.
EquivalentClasses(d1,d2,...dn)
=>
T(EquivalentClasses(di,d(i+1)))
i=1,...n-1
I am sure there are others.
It is a bit clunky to not allow trees of EquivalentClasses
in the concrete syntax i.e. prohibit:
_:a owl:equivalentClass _:b .
_:a owl:equivalentClass _:c .
But I can't see how to do that well.
(Note it is nice to get owl:disjointWith and owl:equivalentClass
behaving similarly - owl:disjointWith is distinctly harder).
Jeremy