On 10/1/14, 3:14 PM, Antoine Isaac wrote:
  I do understand the wish to
> separate constraints from axioms. But I am afraid of the end result if
> we make this separation. What if we end up with a constraint language
> (say DSP) that has constraint which can also be expressed in the
> ontology language (OWL).
>
> Continuing on class disjointness: we certainly want it as a constraint,
> it's already in our requirements. Should we refrain from putting it in
> the constraint language, because it's in the ontology language? Or
> should we try to separate disjointness-constraint from disjointness-axiom?

All,

This is what I meant when I stated that we are heading into dangerous 
territory. Dangerous not that we shouldn't do it, but that we need to 
think carefully about both the closed world and open world implications 
for each AP function. Fortunately, I believe we will be able to do some 
actual testing of examples, and that will help us be sure we are 
developing something workable.

The DSP today does not provide a way to assign classes as domains to 
properties. It does allow the definition of ranges, but those must not 
conflict with the ranges already defined in the ontology. I think that, 
while a bit tricky, can be managed. We should look at the cases that we 
have (and even think beyond those) to see if we can find a case where we 
would add a domain in the closed world that is not desired in the open 
world. If so, then we should add that. My guess, however, is that 
"classes" in the actual RDF sense may not have a great deal of use in 
APs, and that description templates will perform the function that we 
often call classes when talking about data design. (*)

 > should we try to separate disjointness-constraint from 
disjointness-axiom?

I would say yes. A disjointness constraint is actually different (both 
semantically and in practice) from the OWL disjointness axiom. I see no 
problem with adding disjointness to an AP where such disjointness is 
needed in the applications that will use the AP (data creation, quality 
control, documentation of your "data set"). In fact, I believe I have 
seen such constraints being used in validation functions that use 
SPARQL, and it doesn't seem to be a problem. As we know (and Tom and I 
will show some examples in Austin), disjointness in the open world can 
be ill-advised precisely because it does not mean the same as 
disjointness in the closed world. In the closed world it may be a common 
requirement; in the open world it can greatly interfere with data 
compatibility. The same is true of cardinality (which has a very 
different meaning in the open world).

I do not see APs as duplicating the OWL axioms -- although the natural 
language terms we use may be the same, the functionality is quite different.

Obviously, this is what we need to keep in mind as we go through our use 
cases. I don't know what problems might arise when we get into the details.

kc

(*) I'm fantasizing a UI that will help people see the current domain, 
range, and other ontology definitions and will at least alert them to 
possible conflicts with what they develop in an AP. I don't know if it 
can be done...

-- 
Karen Coyle
[log in to unmask] http://kcoyle.net
m: 1-510-435-8234
skype: kcoylenet/+1-510-984-3600