Re: Action-317 Review of Conformance and Test Cases

On Wed, Apr 1, 2009 at 02:16, Alan Ruttenberg <alanruttenberg@gmail.com> wrote:
> Here is my review of the Conformance and Test Cases document.

<snip>

Adding to Ian's response on the following ...

> Section 3.1.1.2
>
> 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?

> 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.

<snip>

Ian deferred for the remaining items...

> Section 3.1.2.4

> I would move "Details on the changes of the test case format as
> compared to WebOnt are found in Section 3.5." to immediately after the
> sentence
>
> "Existing test ontologies, such as the ones used by the WebOnt working
> group [OWL Test Cases], have not been crafted this way and do not meet
> the above requirements."

This change was made see [webont-changes-diff].

> "it is, however, not necessary to compute entailments of this ontology
> in order to use the provided test case documents"
>
> I'm not clear on why this is the case. Strictly based on looking at
> the ontology there are cases where it looks like entailments are
> needed (for example :semantics property of
> :alternativeSemanticsTest). Will these entailments not be necessary
> because they will be stated explicitly in the test documents?

Yes, the test case documents contain complete positive and negative
assertions for the semantics, species, and profile properties.

> Section 3.2.2
>
> There is no class for syntactic translation tests.

I have added a class. See [translation-class-diff].

> "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.

> Section 3.2.3
>
>
> "The individual :FUNCTIONAL indicates that all functional syntax input
> ontologies are normative"
> Here and elsewhere the scope of "all" wasn't clear.

I had thought that the sentence that begins the previous paragraph
removed the ambiguity, but I reworded the items in this list to be
more explicit (at the cost of redundancy).  See [syntax-diff].


> The choice of ObjectOneOf( :RDFXML :FUNCTIONAL :OWLXML ) unecessarily
> limits extensibility of the (future contributed) tests to other
> syntaxes. Better to use a class and subclasses so that other syntaxes
> can be added later.
>
> Declaration(Class(:OWL2Syntax))
> SubClassOf(:RDFXML :OWL2Syntax)
> ...
> ObjectPropertyRange( :normativeSyntax :OWL2Syntax)

I agree that we can make be more future friendly.  I disagree with
your alternative because I don't understand what you would gain from
modeling the individual syntaxes as a class.  E.g., what would an
instance of the :RDFXML class represent?    I've added a :Syntax class
and made the individuals above members of it.  See [syntax-diff].
This change did not require any change to the test cases.

> Here and elsewhere property ranges are given, but not domains
> (:TestCase). Any reason not to?

Specifically for this case :normativeSyntax is also used for imported
ontologies.  See section 3.2.7.

For the general case, I've tried to abstain from adding axioms if
there wasn't a clear benefit in accurate description of the test case
or reduction of ambiguity that may be present in the text.  It don't
see a clear benefit to adding domain axioms - if someone uses a
property, e.g., :identifier, to describe a resource that isn't a test
case, I - as test author or test consumer - don't care, because those
things aren't relevant to me.  To this end, all of the range axioms
could be replaced by restrictions on the test case class, but I have
chosen range axioms because they a briefer and easier for many users
to understand than subclass axioms with property restrictions.

> Section 3.2.6
>
> Wording
> "The following axiom reflects the fact that OWL 2 EL and OWL 2 QL are
> syntactic profiles of OWL 2 DL."
>
> profile != subset in our spec. Use "subset"? "restriction" or just say
> "are also" OWL 2 DL.
>
> Also, 2.1.1 says: "An OWL 2 RL ontology document is an OWL 2 DL
> ontology document" so shouldn't RL be mentioned here too?


Yes.  I have reworded this section.  See [profile-diff].


> Section 3.2.8
>
> Do we really want to keep rejected test cases? Why?

To record that the test case was proposed and rejected by the WG (if
such an event occurs).  That is different from the test case never
existing or never being proposed.  I believe the same rationale was
used by WebOnt, from whom I adopted the status.

> For test cases
> contributed after the end of the working group, does it make sense to
> consider these "proposed" given that there may be no one to propose
> them to? Should we add another value "contributed"?

When submitted, tests are not given any status - this is the state of
most of the tests currently in the test cases wiki.  The "contributed"
state you're suggesting is equivalent to this - existence without
asserted status.

> Section 3.2.9
>
> :identifier, :creator, :description seem like dc:identifier,
> dc:creator, rdfs:comment.
> Should we reuse these previously defined properties?

We describe in the document how we intended the properties
:identifier, :creator, and :description to be used.  It is permissible
for someone to map them to third party properties with similar uses,
but I don't see that we benefit from providing this mapping.  For
dublin core specifically, I believe we would run into the problem that
it is not an OWL ontology and therefore cannot be imported.


> Allowing a rdfs:label seems like a good idea.

We do nothing to prevent arbitrary annotations on the test cases.  In
fact, some of the test cases have rdfs:comments describing how they
were changed (e.g., some had ontology headers added).  Labels could be
added without any changes to the T&C document or the test case
ontology.

> It may be worth doing an audit of the test ontology to see if there
> are other opportunities to use already defined properties.

See above.

> I wonder if :identifier should be further restricted by a pattern
> facet, as the logical definition doesn't follow the textual one.

I certainly don't want to be responsible for defining a pattern facet
to match only irelative-ref, and don't know if it is possible.  After
review I found that the narrative text was unnecessarily restrictive.
It has been relaxed to reflect the state of the test repository.  See
[identifier-diff].

> 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?

> 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

> Section 3.2.14
>
> Annotation(rdfs:isDefinedBy <url to the conformance and test specification>)?

Yes. See [is-defined-by-diff].

> wording
> "# The following "intersection properties" have not been described in
> the test and conformance document but are used"
>
> s/described/enumerated/
>
> They are described in 3.2.1

Yes. I removed the comment altogether in [intersection-prop-diff]

> Section 3.5.1
>
> "instead of using multiple files for each involved ontology"
> s/multiple/separate/

Yes. See [separate-diff].

-- 
Mike Smith

Clark & Parsia

[webont-changes-diff]
http://www.w3.org/2007/OWL/wiki/index.php?title=Conformance_and_Test_Cases&diff=21181&oldid=20353
[translation-class-diff]
http://www.w3.org/2007/OWL/wiki/index.php?title=Conformance_and_Test_Cases&diff=21441&oldid=21438
[syntax-diff] http://www.w3.org/2007/OWL/wiki/index.php?title=Conformance_and_Test_Cases&diff=21438&oldid=21320
[profile-diff] http://www.w3.org/2007/OWL/wiki/index.php?title=Conformance_and_Test_Cases&diff=21443&oldid=21441
[is-defined-by-diff]
http://www.w3.org/2007/OWL/wiki/index.php?title=Conformance_and_Test_Cases&diff=21444&oldid=21442
[intersection-prop-diff]
http://www.w3.org/2007/OWL/wiki/index.php?title=Conformance_and_Test_Cases&diff=21445&oldid=21444
[separate-diff]
http://www.w3.org/2007/OWL/wiki/index.php?title=Conformance_and_Test_Cases&diff=21446&oldid=21445

Received on Tuesday, 7 April 2009 14:42:02 UTC