W3C home > Mailing lists > Public > public-rdf-shapes@w3.org > July 2014

Re: owl for interface constraints

From: Simon Spero <sesuncedu@gmail.com>
Date: Sun, 20 Jul 2014 09:44:50 -0400
Message-ID: <CADE8KM6ekGQU5ChCchT0LJhg0cwTHWUzvMcqbd1Ldfm2wR+8Rg@mail.gmail.com>
To: Sandro Hawke <sandro@w3.org>
Cc: Kendall Clark <kendall@clarkparsia.com>, "Eric Prud'hommeaux" <eric@w3.org>, "Dam, Jesse van" <jesse.vandam@wur.nl>, Jerven Bolleman <jerven.bolleman@isb-sib.ch>, "public-rdf-shapes@w3.org" <public-rdf-shapes@w3.org>, Evren Sirin <evren@clarkparsia.com>, Jose Emilio Labra Gayo <jelabra@gmail.com>, "Peter F. Patel-Schneider" <pfpschneider@gmail.com>, Dimitris Kontokostas <kontokostas@informatik.uni-leipzig.de>
Sandro -
It is absolutely normal to assert axioms in an ontology that restrict the
models of terms in another ontology. It's an important part of ontology

Think about all the axioms that are defined on Thing and Nothing.

The key things to realize is that these axioms *only hold for that
ontology*, and that statements made that are true in the restricted
ontology are true in the unrestricted ontology, but not vice versa.  Fusion
systems deal with this.

*ANY* method you use to constrain the set of things that some ontology
allows to exist is *BY DEFINITION* creating a new ontology using the terms
of the original.
 On Jul 20, 2014 8:21 AM, "Sandro Hawke" <sandro@w3.org> wrote:

> On 07/20/2014 05:05 AM, Peter F. Patel-Schneider wrote:
>> On 07/20/2014 01:10 AM, Eric Prud'hommeaux wrote:
>>> * Evren Sirin <evren@clarkparsia.com> [2014-07-19 22:55-0400]
>> [...]
>>  One of the features of Resource Shapes is that, while it *can* be
>>> attached to a type, it frequently is not. Arthur Ryman spoke of this
>>> [[
>>> constraint language should be independent of any vocabulary or
>>> ontology
>>> ]] — <http://www.w3.org/mid/OFF14B15B5.802B33E2-
>>> ON85257D0A.004C62E1-85257D0A.005240FE@ca.ibm.com>
>>> and emphasized it in
>>> <http://www.w3.org/mid/OF026C08BD.7F379A54-ON85257D15.00456170-85257D15.
>>> 0047EB06@ca.ibm.com>
>> Taken literally, this statement is rather extreme.  Constraint languages
>> that are independent of vocabularies can only talk about reachability and
>> connectedness.  I don't think that this is what is wanted here.
> I think what Arthur and Eric are talking about is independent control.
> They (and I) want one party to create and maintain a vocabulary/ontology,
> while multiple other (unrelated) parties are able to create and maintain
> reusable sets of constraints involving that vocabulary (and not violating
> the constraints in that ontology).
> They presume something which perhaps you do not, which is that the the
> party which hosts the IRIs comprising a vocabulary is empowered to maintain
> the definitive ontology for that vocabulary.  That's why I wrote
> "vocabulary/ontology", because with this Linked Data approach, the two go
> together.  I think this approach is widely accepted, although I don't think
> it's explicit in any W3C Recommendation.  (As I recall, you and I have been
> in several Working Groups which considered saying something about this, and
> you opposed it.   I may have misunderstood.)
> What I hear you saying here is that regardless of that, it's reasonable
> for other people to publish/maintain what we might call a "secondary" or
> "third-party" ontology, which contains axioms concerning someone else's
> vocabulary.    My sense is this kind of thing is generally regarded as a
> Bad Practice, although I don't offhand know why, and there might not be any
> good reason.  I think I've seen people yelled at for suggesting something
> like this (which doesn't necessarily mean it's a bad idea).
> For my use case, I think the important thing is to be able to attach
> constraints to interfaces.  To simplify somewhat, I want to say when you're
> POSTing to URL U, if you want things to work properly, you MUST include
> exactly one foaf:firstName on each instance of foaf:Person.
> I can imagine writing that as:
>    <U> eg:interfaceConstraints <UC>
> and then <UC> would contain OWL of the form:
>    foaf:Person owl:subClassOf [
>       a owl:Restriction;
>       owl:cardinality 1;
>       owl:onProperty foaf:firstName
>    ].
> I don't really know Manchester syntax, but maybe it would be something
> like:
>    Class: foaf:Person
>       Types: foaf:firstName exactly 1
> Is that how you would propose I get the functionality I want?
> Somewhere I'd need to say that this OWL is to be understood with closed
> world semantics, right?
> Are there other problems I might have?
>      -- Sandro
>  One can argue that particular vocabularies/ontologies should permit
>> multiple sets of constraints.  I agree with this argument.  This does not
>> make the constraints independent of the vocabulary or ontology, however.
>>  In fact, every example of ShEx that I have seen is very tied to a
>> particular vocabulary.
>> OWL and RDFS do not fail on this point at all.  One can use OWL and RDFS
>> in a very flexible manner, where there is a base ontology and additional
>> axioms.  A constraint system using OWL or RDFS can work in a similar
>> fashion.
>> Even StarDog ICV can be used in this manner.  All you have to do is have
>> an overall file that imports the base ontology and separately
>> constraint-imports the constraints.  Different uses can have the same
>> ontology and different constraints.  Some uses can even have just the
>> constraints.  One could also have a trivial modification of StarDog ICV
>> that had an extra explicit input - the constraints.
>> Argument 2 in http://lists.w3.org/Archives/Public/public-rdf-shapes/
>> 2014Jul/0076.html does not require anything that cannot be provided by
>> StarDog ICV and many other constraint setups that are built on RDFS or OWL.
>> It is very hard to see how ShEx constraints can be associated with
>> instances of RDFS types.  I view the ability to associate constraints with
>> instances of types as the most important aspect of a constraint system,
>> hence my questions about how this can be done in ShEx.
>> peter
Received on Sunday, 20 July 2014 13:45:17 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:02:39 UTC