Re: ContainerHierarchy again

On 5 Mar 2014, at 11:25, henry.story@bblfish.net wrote:

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

Ok I tried this out, and it does not seem to be the problem I thought. I wrote out the
ontology with the cardinality restrictions in the following file

https://github.com/bblfish/ldp/blob/master/ldp.ttl

and then tested it with pellet. First I get the correct hierarchy

$ sh pellet.sh classify --input-format  Turtle ../LDP/ldp.ttl 
Classifying 10 elements
Classifying:  100% complete in 00:00
Classifying finished in 00:00

 owl:Thing
    rdf:Property
    rdfs:Resource
       ldp:BasicContainer
    ldp:Resource
       ldp:Source
          ldp:Container
             ldp:IndirectContainer
                ldp:DirectContainer
                   ldp:BasicContainer

And then I don't get  the feared ldp:contains owl:sameAs o:asset entailment

$ cat ldp.entail.ttl 
@prefix o: <http://example.org/ontology/>.
@prefix owl: <http://www.w3.org/2002/07/owl#> .
@prefix ldp: <http://www.w3.org/ns/ldp#> .

ldp:contains owl:sameAs o:asset .
owl:sameAs owl:sameAs owl:sameAs .

21:32:57 - ~/Programming/OWL/pellet-2.3.1
hjs@bblfish[0]$ sh pellet.sh entail --verbose --entailment-file ldp.entail.ttl ../LDP/ldp.ttl 
There are 1 input files:
../LDP/ldp.ttl
Start loading
Finished loading in 00:00:00.560
Input size: Classes = 10, Properties = 15, Individuals = 7
Expressivity: SRON
Loading entailment file: 
ldp.entail.ttl
Check entailments for (2) axioms
Start Checking
Finished Checking in 00:00:00.046
Non-entailments (1): 

1) asset sameAs contains

Timer summary:
Name     | Total (ms)
=====================
main     |        845
loading  |        560
Checking |         46

that is I think because the ldp:IndirectContainer is really just responsible for the membership triples and not the 
containment triples. Even though both are similar in that they are consequences bound to happen on a successful 
POST, the IndirectContainer "membership predicates" (rules) only deal with one set of relations... It is only in the 
BasicContainer that they happen to be the same.

The bindingRules makes this easier to understand in my view, but this still seems to work. With the binding
rules version I was working on, it should be easy to show that a BasicContainer is also following the same 
principle as the other containers.

Sorry for setting off the alarm...

Henry