Re: ContainerHierarchy again

On 5 Mar 2014, at 01:35, ashok malhotra <ashok.malhotra@oracle.com> wrote:

> In programming languages, subclass relationships come with certain guarantees
> such as :  a method that runs on an instance of the parent class will also run on
> an instance of the subclass.
> 
> What are the equivalent guarantees on RDF subclasses?
> In other words, what are the rules on behavior between a parent class and a subclass?

classes in RDF are (very close to ) mathematical Sets. They don't change, they don't have
behavior.  All members of a subclass are members of a subclass. 

So if something is true of all members of a superclass then it is true of all members 
of a subclass for example. RDFS and owl map out a lot of these rules.

For example in the ontology I wrote up we had

ldp:membershipResource a rdf:Property,
         rdfs:domain ldp:IndirectContainer .

ldp:membershipResource a rdf:Property;
         rdfs:domain ldp:IndirectContainer .

ldp:insertedContentRelation a rdf:Property, owl:FunctionalProperty;
         rdfs:domain ldp:IndirectContainer .

This allows us do conclude from { ?c ldp:membershipResource ?r } that { ?c a ldp:IndirectContainer }.

What we want to say is something stronger though, namely that every ldp:IndirectContainer has these
three relations. We could say:

ldp:IndirectContainer a rdfs:Class, owl:Class;
   rdfs:subClassOf ldp:Container,
                   [ a rdf:Restriction;
                     owl:onProperty ldp:hasMemberRelation;
                     owl:cardinality 1;
                   ],
                   [ a rdf:Restriction;
                     owl:onProperty ldp:insertedContentRelation;
                     owl:cardinality 1;
                   ], 
                   [ a rdf:Restriction;
                     owl:onProperty ldp:membershipResource;
                     owl:cardinality 1;
                   ].

This would tell us that every IndirectContainer has only 1 of these three relations.
But then we can no longer say that the ldp:contains relations is a restriction on 
the ldp:hasMemberRelation, since then we'd have two of each relation, which by the
above restriction would be owl:sameAs each other.

To take out example 

<http://example.org/netWorth/> a ldp:DirectContainer;
   dcterms:title "The assets of JohnZSmith";
   ldp:membershipResource <http://example.org/netWorth/nw1/>;
   ldp:hasMemberRelation o:asset;
   ldp:contains <a1>, <a2>.

It would then follow that

   o:asset owl:sameAs ldp:contains .

which is not what we want. 

If we then set cardinatlity restrictions to 2 then we would no longer know which of the 
two ldp:hasMemberRelation is meant to go with which ldp:insertedContentRelation. And
yet that is what we are doing when we have an IndirectContainer that also has the ldp:contains
relation.

I am trying to see if I can get Pellet to come up with this conclusion by itself.

This shows I think that we need to model what we are doing using ldp:bindingRules
where an ldp:IndirectContainer is restricted to two Rules, and each rule itself can only have
one of each of the relations. I think things will work out in that case.

============================================
So I think we do have a serious modelling problem here. 
Perhaps if someone who is better at owl can work this out with me we'd be able to get this 
worked out cleanly.
============================================

This is how far  I got until now...

ldp:HttpActionRule a rdfs:Class;
   rdfs:comment """
      a rule on what consequences will occur on POSTing to a container.
   """.

ldp:bindingRule a rdf:Property;
   rdfs:label "binding rule";
   rdfs:domain ldp:Container;
   rdfs:range ldp:HTTPActionRule .

ldp:IndirectContainerRule rdfs:subClassOf ldp:HttpActionRule .
ldp:DirectContainerRule rdfs:subClassOf ldp:IndirectContainerRule .

ldp:ContainerRule rdfs:subClassOf ldp:DirectContainerRule ;
   rdfs:label "ContainerRule";
   rdfs:comment """
     the rule that on POSTing creates an ldp:contains relation, etc... 
   """.


ldp:Container 
   owl:equivalentClass [ a owl:Restriction;
         owl:onProperty ldp:bindingRule;
         owl:someValuesFrom ldp:ContainerRule ].

ldp:IndirectContainer 
    owl:equivalentClass [ owl:intersectionOf 
           ( ldp:Container 
             [ a owl:Restriction; 
              owl:onProperty ldp:bindingRule;
              owl:maxQualifiedCardinality 2;
              owl:onClass ldp:IndirectContainerRule ] 
           )
        ].

ldp:DirectContainer 
    owl:equivalentClass [ owl:intersectionOf 
           ( ldp:Container 
             [ a owl:Restriction; 
              owl:onProperty ldp:bindingRule;
              owl:maxQualifiedCardinality 2;
              owl:onClass ldp:DirectContainerRule ] 
           )
        ].

Henry



> 
> On 3/4/2014 3:38 PM, Kingsley Idehen wrote:
>> On 3/4/14 1:16 PM, henry.story@bblfish.net wrote:
>>> At the last meeting there was a resolution to move back to the previous positon 
>>> on container hierarchies, the position called "the minimal consensual position"
>>> in 
>>> 
>>>    https://www.w3.org/2012/ldp/wiki/ContainerHierarchy
>>> 
>>> But that wiki page shows how the minimal consensual position we have currently
>>> + the decisions we have previously come to lead to hierarchy
>>> 
>>> IndirectContainer
>>>    DirectContainer
>>>       BasicContainer
>>> 
>>> In RDF subclass relations DO NOT mean dependence of one subclass
>>> on another. You can easily deprecate classes without subclasses or
>>> superclasses without this leading to legacy issues.
>>> 
>>> All the subclass relations mean is that you cannot have objects that are in one
>>> class and not the superclass as shown by the picture
>>> 
>>>  https://www.w3.org/2012/ldp/wiki/ContainerHierarchy#LDP-BC_.3C:_LDP-DC_.3C:_LDP-IC_.3C:_LDPC
>>> 
>>> 
>>> So I think it is misleading in fact to now show the classes as having no relation to each
>>> other when we know they do.
>>> 
>>> Henry
>> 
>> Is this addressed to me or everyone else? 
>> 
>> "
>> In RDF subclass relations DO NOT mean dependence of one subclass
>> on another. You can easily deprecate classes without subclasses or
>> superclasses without this leading to legacy issues.
>> "
>> 
>> You appear (if this is directed to me) to be assuming that I am I disagreeing with, or contradicting, the claim above? 
>> 
>> FWIW: subclasses are useful in the context of inference, when the relations in question (e.g., rdfs:subClassOf) are transitive in nature.
>> -- 
>> 
>> Regards,
>> 
>> Kingsley Idehen	      
>> Founder & CEO 
>> OpenLink Software     
>> Company Web: http://www.openlinksw.com
>> Personal Weblog: http://www.openlinksw.com/blog/~kidehen
>> Twitter Profile: https://twitter.com/kidehen
>> Google+ Profile: https://plus.google.com/+KingsleyIdehen/about
>> LinkedIn Profile: http://www.linkedin.com/in/kidehen
>> 
>> 
>> 
>> 
> 

Social Web Architect
http://bblfish.net/

Received on Wednesday, 5 March 2014 10:26:58 UTC