owl for interface constraints

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 12:21:13 UTC