W3C home > Mailing lists > Public > public-owl-wg@w3.org > April 2009

Re: Action-317 Review of Conformance and Test Cases

From: Mike Smith <msmith@clarkparsia.com>
Date: Tue, 14 Apr 2009 11:50:56 -0400
Message-ID: <42485a40904140850j336d735dl4804ac6ed81dfe0@mail.gmail.com>
To: W3C OWL Working Group <public-owl-wg@w3.org>
On Mon, Apr 13, 2009 at 12:36, Alan Ruttenberg <alanruttenberg@gmail.com> wrote:
> Summary:
> The only substantive concern is about structure preserving being the
> criterion for translation tests.

You are correct that pass/fail criterion for syntax translation tests
is based on structure.

> I think we need a translation test
> that checks that the models are the same, verifying the statement in
> the RDF mapping document. "More precisely, for any OWL 2 DL ontology
> O, let G = T(O) be the RDF graph obtained by transforming O as
> specified in Section 2, and let OG be the OWL 2 DL ontology obtained
> by applying the reverse transformation from Section 3 to G; then, O
> and OG are logically equivalent — that is, they have exactly the same
> set of models"

This turns a syntactic test into a semantic test, which we can
approximate using entailment tests.  Do (positive and negative)
entailment tests with RDF/XML premise and conclusions meet your

As you noted on the telecon, this approach does present some problems
with respect to annotations, which are not needed for logical
equivalence.  I do not have a solution that avoids reference to
structural equivalence and preserves annotations.

> We could also have a test for structure preserving, but this seems less important (to me).

Yes, we have such tests now and they are useful for tools that are
interested in parsing multiple syntaxes, such as the OWLAPI.  It is
important that we provide some tests for tools which aren't reasoners
-- the current syntax translation and profile identification tests do
not require any reasoning.

> Other comments are interspersed. At places I have made suggestions but
> leave it to you to make the decision.


>>> Section
>>> Do we want to say that translations preserve structure, or preserve
>>> semantics? Currently it says structure which may be too strong.
>> Structure was intended.  Can you elaborate why you think this may be too strong?
> For example, the RDF mapping for
> ObjectPropertyAssertion( ObjectInverseOf( OP ) a1 a2 ) =>  T(a2) T(OP) T(a1) .
> Does not preserve structure, as after reverse translation we get
> ObjectPropertyAssertion( a2 OP a1 )

Correct, not all ontologies can be round-tripped through RDF.  For
those ontologies which can be round tripped, we can create useful
syntax translation test cases in all syntaxes.  For those which can't
be universally round tripped, the tests will only be useful for
syntaxes which permit round-tripping.

We should keep this constraint in mind when we consider coverage of
the test cases.  I don't think that deficiencies in some cases
motivate discarding the benefits in a larger number of other cases.

>>> Are not all the ontologies in a translation test normative?
>> Correct.  Section 3.2.3 explicitly states this.  This allows us to
>> have, e.g., an ontology that in functional syntax has a ternary
>> SameIndividual axiom, and provide a normative translation into
>> OWL/XML, even though a structure preserving translation into RDF/XML
>> is not possible.
> Still not understanding this.
> Your last sentence another reason to reconsider structure preserving
> as a criterion. It's odd to not be able to to have normative
> translation tests to and from RDF/XML, the official exchange syntax.

See my comment above.  It's acceptable to me that some test cases
might not be useful in all syntaxes.


>>> "In practice, semantic tests will indeed have only one premise,
>>> conclusion, or non-conclusion, but for convenience each of those may
>>> be provided in multiple syntactic forms. This is the reason why the
>>> above assertions do not require exact cardinalities."
>>> Do we expect there to be at most one in each syntax? If so, you can
>>> use qualified max cardinality here.
>> No.  The range of the property is xs:string.  There is not a standard
>> datatype which will permit functional serializations but not RDF/XML
>> serializations.
>> We could approximate your request with cardinality restrictions on the
>> typed properties (e.g., rdfXmlPremiseOntology), but I would prefer not
>> to.  I do not see a clear benefit from the additional restrictions and
>> it would reduce flexibility and expressivity by preventing alternative
>> serializations within the same syntax.
> ok, though note that if you have alternative serializations with the
> same syntax, you have to have them all be normative or none, afaict.

Yes, your observation is correct.  This constraint is unfortunate, but
keeps things simpler.

>>> Values for creator and description should perhaps be rdf:text rather
>>> than xsd:string to allow for (future) translations and non-english
>>> contributions.
>> Yes, perhaps.  Unfortunately, here we are constrained by current
>> tooling.  I'm comfortable with the trade-off of losing some future
>> translations and gaining the ability to use tools that have yet to be
>> updated for rdf:text.  Do you think this is important enough to
>> require a change?
> Why not leave it as a literal for now, and then tighten it later? I
> don't think we'll have problems with numbers being passed in as
> strings.
> But your call.

Ok, see [remove-string-ranges]. (Note that the change
[identifier-diff] is also included here, it was referenced in my
previous email, but not done in the wiki).

>>> Section 3.2.12
>>> SubAnnotationPropertyOf(foaf:page :specRef)?
>>> Section 3.2.13
>>> SubAnnotationPropertyOf(foaf:page :issue)?
>> First, see my comment re: section 3.2.9. Second, :specRef and :issue
>> are object properties, not annotation properties. Third, FOAF is not
>> an OWL ontology
> I don't see why these should be object properties. Personally I'd make
> them annotation properties and leave open the possibility of someone
> foafing later. However, I'll accept your judgement either way.

I'm leaving these as is.  I've gotten feedback from other parties that
using object properties in this case is more FOAF friendly (foaf:page
is declared an object property), so I don't feel there is a consensus
on what preserves a pro-FOAF future.

Mike Smith

Clark & Parsia

Received on Tuesday, 14 April 2009 15:51:38 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 16:41:58 UTC