W3C home > Mailing lists > Public > public-owl-wg@w3.org > January 2008

ISSUE-94 (n-ary constucts and RDF): Problem with roundtripping when going from functional-style syntax into RDF and back

From: OWL Working Group Issue Tracker <sysbot+tracker@w3.org>
Date: Wed, 16 Jan 2008 20:37:39 +0000 (GMT)
To: public-owl-wg@w3.org
Message-Id: <20080116203739.A35C45F70A@stu.w3.org>

ISSUE-94 (n-ary constucts and RDF): Problem with roundtripping when going from functional-style syntax into RDF and back


Raised by: Boris Motik
On product: 


At the teleconference on 16/01/2008, we decided that we might close ISSUE-2 and open a new issue on syntax round-tripping the functional-style syntax, so here is the new issue.

1. Problem description

The functional-style specification contains several n-ary axioms, which are currently mapped into n or n^2 binary axioms in OWL/RDF. This prevents round-tripping: given an ontology O, storing it into an RDF graph and then reading it back does not always produce the original ontology O.

For example, assume that O contains the following axioms:

(1) EquivalentClasses( c_1 ... c_n )

Under the current translation into RDF, this will produce the following RDF graph G:

(2) c_1 owl:equivalentClass c_2
(3) c_2 owl:equivalentClass c_3
(4) c_{n-1} owl:equivalentClass c_n

If we now read G back into the functional-style syntax, we get the ontology O' containing the following axioms:

(5) EquivalentClasses( c_1 c_2 )
(6) EquivalentClasses( c_2 c_3 )
(7) EquivalentClasses( c_{n-1} c_n )

2. Does this really matter in practice?

Ontology editors such as Protégé typically allow for n-ary constructs. Hence, it is likely that a user might enter an axiom such as (1) and save the ontology; after restarting the editor and loading the saved ontology, the user might be surprised that he gets new axioms. In fact, the new binary presentation might be quite inconvenient for users: they might have used an n-ary construct in order to have fewer axioms in the list of axioms that they work with.

Hence, I would say that this does really matter in practice.

>From the point of view of a specification, without round-tripping the specification seems contradictory: we say that OWL/RDF is the main syntax for OWL, but it does not provide a way to serialize everything that OWL provides, at least not without changing the syntactic structure of an ontology. I believe this is not nice from a principal point of view.

3. What n-ary constructs are there?

- DisjointUnion
- EquivalentClasses
- DisjointClasses
- EquivalentObjectProperties
- DisjointObjectProperties
- EquivalentDataProperties
- DisjointDataProperties
- SameIndividual
- DifferentIndividuals

Of these, DisjointUnion is already mapped to an n-ary RDF construct. Furthermore, there is widespread consensus in the WG that DisjointClasses and DifferentIndiviudals should be mapped into n-ary constructs. (In fact, DifferentIndiviudals was already mapped to an n-ary construct in OWL 1.0, and not using it in OWL 1.1 is a bug that will be corrected as part of ISSUE-3.)

Thus, we have a total of 6 additional constructs that would need an n-ary equivalent.

4. Proposed solution

The general approach to handling this issue would be along the lines of AllDifferent from OWL 1.0. Consider again axiom (1). If n is equal to 2, then, to be compatible with OWL 1.0, we might translate the axiom into (2). If n is different from 2, however, we would translate it into the following RDF triples:

(8) _:x rdf:type owl11:AllEquivalentClasses
(9) _:x owl11:members T(SEQ c_1 ... c_n)

We could use here owl11:members for all n-ary constructs. Thus, we need the following new vocabulary items:

- owl:members
- owl:AllEquivalentClasses
- owl:AllDisjointClasses
- owl:AllEquivalentObjectProperties
- owl:AllDisjointObjectProperties
- owl:AllEquivalentDataProperties
- owl:AllDisjointDataProperties
- owl:AllSameIndividual

There was some objection to the vocabulary bloat. However, most users are unlikely to deal with RDF directly anyway: they will use editors for their ontologies, and these editors can hide the underlying complexity.


Received on Wednesday, 16 January 2008 20:37:52 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:42:02 UTC