Re: owl for interface constraints

On 07/20/2014 05:20 AM, Sandro Hawke 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).

Sure, that's perfectly fine, and fits into StarDog ICV and other proposals.

> 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.

Again sure.  There may be reasons to not do this, but in a particular 
community it is very convenient to have one party control the ontology.

 > 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.)

Well, I am utterly opposed to making this a requirement.  The "definitive" 
ontology may have an error. The party initially in control may disappear. 
There are lots of reasons that you may be forced out of the standard 
situation, but the standard situation has a lot going for it.

> 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.

Well, I do think this, but I'm not arguing for it here.  Instead, I'm arguing 
for exactly the same thing that I think is being argued for elsewhere. 
Different consumers of information conforming to an ontology may want 
different constraints to be checked against that ontology.  The criticism that 
was being levelled at OWL/RDFS solutions is that they couldn't do this.

 > 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).

There are lots of good reasons to want to extend an ontology.  You may want to 
extend the vocabulary.  You may even want to augment the meaning of the 
vocabulary in the ontology.  Sure, bad things may happen when you do this 
because your extensions conflict with the use of the ontology, but good things 
may also happen.

> 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.

Sure, differing uses of particular vocabularies/ontologies may want different 
sets of constraints.  No problem, as I have said earlier, rebutting other 
people who have claimed that solutions based on RDFS or OWL can't do this.

> 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?

Something like that, I think, although the exact tokens might be different.

> Somewhere I'd need to say that this OWL is to be understood with closed world
> semantics, right?

Yes, that would be the purpose of having ex:interfaceConstraint, or something 
similar.

> Are there other problems I might have?

Well, probably lots.  :-)

>
>       -- Sandro


peter



>
>> 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 14:52:22 UTC