Thanks, Thomas. Yes, these are interesting questions. I believe that the 
Stardog ICV software does have an analysis of the OWL2 OW/CW, but I 
can't find that in their documentation -- I suspect that one has to be a 
customer, or that it's considered proprietary. An independent analysis 
would probably be helpful, although it may get different results from 
the ICV algorithms. (You should be able to get at least one strong 
publication from such an analysis!)

I'm pondering what "disjoint" means in the closed world -- ?? that they 
don't share any properties? I think that the DSP does that in an 
entirely different way: it defines the properties for each description. 
So it's a very different approach.

Although either SPIN or ICV or ShEx may be the language of validation 
(and I greatly appreciate Kai's view that they may *all* be available 
for validation and one chooses which works best for one's data), I'm not 
sure that they are sufficient as languages for a somewhat friendly 
application profile standard. What I would consider the greatest success 
for us would be to create something that can be mapped to any reasonable 
validation method, but that makes it easy for people to define the 
constraints they want to use in their application. BIBFRAME has used a 
somewhat reduced DSP in this way: the AP is what drives the BIBFRAME 
instance data editor. (I would love for us to have a similar editor for 
the *creation* of APs.)

Meanwhile, I've added more to the list of features lacking in the DSP 
[1] that have come up in discussion, and will try to get more out of the 
deliverable. Whether we modify the DSP or create something else, at 
least this connects the requirements with something concrete.

kc
[1] 
http://wiki.dublincore.org/index.php/RDF_Application_Profiles/DSPanalysis

On 10/4/14, 1:37 AM, Bosch, Thomas wrote:
> Hi Karen,
>
> I'm looking forward to the tutorial of you and Tom in Austin, this topic
> is extremely interesting.
>
> The difference between disjointness in the Open and in the Closed World
> is a good starting point.
> I like the idea looking over (all) OWL 2 axioms in order to compare the
> effects of these axioms when assuming CW and OW.
> oWhat are the semantic differences when we want to use OWL 2 axioms for
> validation in a CW.
> This kind of research has to be done.
> Then we can decide what OWL 2 axioms we need and what OWL 2 axioms are
> not applicable when we want to define APs for validation purposes.
> And you're right the need has to result from our use cases.
>
> An actual validation of OWL 2 'axioms' (CWA) could be done using SPIN
> and therefore SPARQL.
> We can base such a validation on what we already have.
>
> Then we should ask which concrete syntax we should use to write APs.
> Using a concrete syntax related to OWL is for sure well known.
>
> I'm looking forward discussing these issues with you and Tom.
>
>
> Cheers,
> Thomas
>
> 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

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