jacco:
[[
I was not happy about the third option in Saterday's straw poll.
I felt I was forced to vote on "leave it to the application", while I was
under the impression that Jeff's proposal was something along the lines of:
"no owl entailment, but provide a well-defined a way that applications
can use to 'map' 1.3 floats on 1.3 doubles etc".
In my opinion, this approach solves the formal owl problems, the
non-monotonic problem and
the interoperability problems.
]]
While I think that Jeff will need to clarify the proposal, here is my
analysis.
1) Some application scenarios will want to treat 1.3^^double in a very
similar way to 1.3^^float. These application scenarios will almost
certainly want to treat 1.299999999999999822^^decimal in a similar way
to 1.299999999999999822^^double, and 1.2999999523^^decimal as similar to
1.2999999523^^float.
Since 1.2999999523^^float is identical to 1.3^^float, and
1.299999999999999822^^double is identical to 1.3^^double, we are likely
to want to treat 1.299999999999999822^^decimal in a similar way to
1.2999999523^^decimal, or we need to have "in a similar way" as not
behaving as an equivalence relation.
2) Some application scenarios will want to treat
1.299999999999999822^^decimal as different from 1.2999999523^^decimal
The solution using primitive base types, moves the problem from the
formal semantics, and the implementation of the formal semantics, to
some part of the application layer, for example, a SPARQL query. This
can be used in a way that is not an equivalence relation e.g. the query:
SELECT ?size
WHERE { eg:car eg:engineSizeInLitres ?size .
FILTER (?size = xsd:decimal("1.3") ) . }
would treat the 1.3 in the query as a decimal, and then the rules for
XPath eq would match both 1.3^^double and 1.3^^float, but not
1.299999999999999822^^decimal.
But if xsd:float("1.3") were used as the value in the query, all three
values would match.
In contrast,
SELECT ?size
WHERE { eg:car eg:engineSizeInLitres "1.3"^^xsd:float . }
would only match the case where the object was a float with that value,
e.g. "1.2999999523"^^float.
Thus the primitive base type solution, combined with SPARQL, allows
applications to choose appropriate matching rules.
===
My understanding is that the other proposal is to allow applications to
choose appropriate *semantics*. So that depending on an application
choice the empty graph may entail either:
(A)
_:a owl:sameAs "1.3"^^xsd:float .
_:a owl:sameAs "1.3"^^xsd:decimal .
or:
(B)
_:a owl:sameAs "1.3"^^xsd:float .
_:a owl:differentFrom "1.3"^^xsd:decimal .
(* see OWL DL note at end)
With this difference in semantics the overall application behaviour then
follows in the desired way, without any explicit application level code,
other than the choice of semantics to use.
Since from the two incompatible entailments (A) and (B) we can form
wider OWL constructs with incompatible interpretations, and this has
been posed as a property of the application rather than the data, I have
great difficulty in seeing how this does not risk interoperability failure.
I suppose we could have say a choice of two possible semantics, and
allow applications to choice between them, and warn RDF and OWL
publishers not to rely on the differences, but this seems quite a costly
solution to rounding problems. I think I was hearing a proposal that was
more open ended than that, and that simply because an application used
semantics entailing
(A)
_:a owl:sameAs "1.3"^^xsd:float .
_:a owl:sameAs "1.3"^^xsd:decimal .
we would not necessarily have the same application using semantics entailing
(C)
_:a owl:sameAs "0"^^xsd:float .
_:a owl:sameAs "0"^^xsd:decimal .
In short, if the people who want application defined semantics are
serious then a proposal in which there is a well-thought extensibility
point is necessary. Inevitably such an extensibility point will result
in non-monotonic behaviour in that the conclusions (A) and (B) above are
mutually inconsistent.
======
* OWL DL
The examples are OWL Full. Similar OWL DL examples would concern the
disjointness or equivalence of hasValue restrictions, roughly
ObjectProperty(p)
DisjointClasses(
restriction( p, hasValue("1.3"^^xsd:decimal ) )
restriction( p, hasValue("1.3"^^xsd:float ) )
)
or
ObjectProperty(p)
EquivalentClass(
restriction( p, hasValue("1.3"^^xsd:decimal ) )
restriction( p, hasValue("1.3"^^xsd:float ) )
)
Either one or other is necessarily true and the other necessarily false,
and my undestanding is that the "application defined" position is that
applications can decide which. It is unclear if any restrictions are
made on the consistency of the application choices.
Jeremy