Re: Action-317 Review of Conformance and Test Cases

Summary:

The only substantive concern is about structure preserving being the
criterion for translation tests. 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"

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

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

-Alan

On Tue, Apr 7, 2009 at 10:41 AM, Mike Smith <msmith@clarkparsia.com> wrote:
> 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 ...

OK, one holdover from Ian's response was rejecting my comment that the
inconsistent ontology be included in the test ontology (as a string).
That way all the parts you need for the testing are in one place.

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

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 )


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

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

ok


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

ok.

>> Section 3.2.2
>>
>> There is no class for syntactic translation tests.
>
> I have added a class. See [translation-class-diff].

ok.


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


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

ok.


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

ok.

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

ok

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

ok

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

Your call. Personally I'd define the three as annotation properties
and then use them as people are used to what they mean and display
tools tend to display them with priority.

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

ok.

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

ok.

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

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

>
>> Section 3.2.14
>>
>> Annotation(rdfs:isDefinedBy <url to the conformance and test specification>)?
>
> Yes. See [is-defined-by-diff].

OK.

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

ok.

>
>> Section 3.5.1
>>
>> "instead of using multiple files for each involved ontology"
>> s/multiple/separate/
>
> Yes. See [separate-diff].

ok.

Thanks.

>
> --
> 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 Monday, 13 April 2009 16:37:35 UTC