Re: Feedback on Henry's proposal for ISSUE-34

On 18 Jan 2013, at 22:56, Arnaud Le Hors <lehors@us.ibm.defendedByom> wrote:

> I agree with Steve. In particular, I don't see why we need to introduce new predicates to indicate membership. 

I did this essentially so that we can discuss the ontological implications of the spec in 
a formal manner. 

Earlier in the thread people were clamouring for clear distinctions, which led to
your proposed vocabulary. If we can express those distinctions in natural language then certainly we can also define them in RDF. The advantage is that we then have a namespace,
and a reference for the words we use, and we can be clear as to what different people
are proposing and how they are disagreeing. Note that the clarity does not mean 
rigid determination of everything. RDF is built on the open world assumption. Every
statement you make in RDF is a restriction on the set of interpretations ( the set
of possible worlds in which that statement is true ), which can be then later clarified
with further restrictions. But you don't close the world by doing it.

It is also possible to specify vocabulary items as unstable and later remove them. Perhaps the following is better.

@prefix ldpx: <http://www.w3.org/ns/ldpx#>.
@prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> .
@prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> .
@prefix vs: <http://www.w3.org/2003/06/sw-vocab-status/ns#> .


ldpx:Container a rdf:Class;
    rdfs:note "deleting a Container deletes all its members";
    vs:term_status "unstable";
    rdfs:subClassOf ldpx:Collection .

ldpx:Aggregation a rdf:Class;
    rdfs:note "This covers what was known as weak aggregation.  Deleting an Aggregation does not imply the deletion of its members" ;
    vs:term_status "unstable";
    rdfs:subClassOf ldpx:Collection.

ldpx:Collection a rdf:Class;
   vs:term_status "unstable";
   rdfs:note "Thing that can have members, that has some notion of containership, to be clarified further" .

ldpx:member a rdf:Property;
    rdfs:domain :Aggregation ;
    vs:term_status "unstable";
    rdfs:note "the relation between an aggregation and its members. Deleting an aggregation does not necessarily delete the members" .

ldpx:contains a rdf:Property;
    rdfs:domain :Container ;
    vs:term_status "unstable";
    rdfs:note "the relation between a container and its contents. Deleting a Container deletes all the resources related to the container by this relation" .
see: http://www.w3.org/2012/ldp/wiki/Issue-34_-_Aggregation:_simple_proposal

> 
> The spec currently defines ldp:membershipPredicate which you can use to specify which predicate you use with a default to rdfs:member. 

ok, so what we have then is 

{
  ldpx:contains rdfs:subPropertyOf rdfs:member .
  ldpx:member rdfs:subPropertyOf rdfs:member .
}  defendedBy [ = g1; foaf:member Arnaud ];
   owl:sameAs :c1 .

It would be a further topic of simplification then to claim

@prefix owl: <http://www.w3.org/2002/07/owl#> .
{
  ldpx:member owl:sameAs rdfs:member .
}  defendedBy g2 ;
   owl:sameAs :c2 .

I think I agree with those, but since that is one further step of reasoning, I did not
want to assume that extra step immediately.  I suppose that c1 and
c2 is currently the default position of the LDP group. So I can add those to my
ontology. 

Unless I name these terms clearly, it is difficult to work out what people are aiming at.
In fact expressing the above questions becomes difficult.

> 
> Unless we want to support a mix bag type of collection in which some members are contained and others are aggregated (i.e., some are deleted and others aren't when the collection is deleted) we don't need to add anything else than what we have. I'd say let's simply reuse ldp:membershipPredicate for Aggregations. 

Ok, so 

{ 
   ldpx:Container owl:disjointWith ldpx:Aggregation  .
}  defendedBy [ = g3; foaf:member Arnaud ];
   owl:sameAs :c3 .

And I think there are excellent reasons to accept that too, most important of which:

1. when you POST content on an ldpx:Container you 
   a) will create a new GETable resource whose name is added to the ldpx:Container via the (implied) ldpx:contains relation
   b) and relative uris in the posted document are interpreted relative to the created resource
2. when you POST a graph onto an LDPR ( which is an LDPA ) then 
  a) the contents of the graph are appended to the LDPR,
  b) the relative URIs are resolved relative to the LDPR
  c) ie: no new resource MUST be created.

The nice thing is that we now have a proof for why those are disjoint. So you can add
me to the members of g3

ie 

  g3 foaf:member <http://bblfish.net/people/henry/card#me> .

> 
> In general, I think we should try and minimize the number of things we invent.

indeed, but using the RDF reasoning tools at our disposal makes things a lot
easier. So we should also make sure we use the tools available to us when 
thinking about things ( I am not saying we need to have an LDP Server implement
reasoning! )

Here is one more thing that came up. In the examples I named the LDPA with
a hash in order to be able to distinguish it from the LDPR it was defined it. Ie:
I named the LDPR <http://localhost:9000/2013/aggReg> and the LDPA 
<http://localhost:9000/2013/aggReg#ion>

I think that there are two further interesting claims people could make

Some would like to say that LDPRs can be LDPAs

{
  [] owl:intersectionOf ( ldpx:Resource ldpx:Aggregation ) 
      owl:differentFrom owl:Nothing .
 }  defendedBy g5;
    owl:sameAs :c5 .

That is compatible with my example. It is just that in the example I tried
not to take the special case. Essentally it would allow 

<http://localhost:9000/2013/aggregation> to contain 

{ <> a ldpx:Aggregation . }

Others may want to claim that

{
   ldpx:Aggregation rdfs:subClassOf ldpx:Resource .
 }  defendedBy g6;
    owl:sameAs :c6 .

And there may be good reason for that, but I am not aware of it yet.


> --
> Arnaud  Le Hors - Software Standards Architect - IBM Software Group
> 
> 
> Steve Speicher <sspeiche@gmail.com> wrote on 01/18/2013 01:23:01 PM:
> 
> > From: Steve Speicher <sspeiche@gmail.com> 
> > To: "public-ldp-wg@w3.org" <public-ldp-wg@w3.org>, 
> > Date: 01/18/2013 01:23 PM 
> > Subject: Feedback on Henry's proposal for ISSUE-34 
> > 
> > Henry's simple aggregation proposal [1] is close to the model I have
> > in mind.  I have a few comments:
> > 
> > 1) ldp:Collection - this seems unnecessary in vocabulary.  We now need
> > to define semantics of it.  For talking/terminology it is ok.  it
> > would be simpler to just have ldp:Container and ldp:Aggregation.  I
> > don't really see one as a subclass as the other.
> > 
> > 2) Why do we need ldp:member and ldp:contains?  What if my model
> > already has terms defined like foaf:knows?  Do I need to insert
> > another triple for each entry of the container vs. just using
> > ldp:containerMemberPredicate?  If I did have my foaf:knows, would it
> > be expected that I would link to ldp:member?  If so simply use
> > owl:SubPropertyOf ?
> > 
> > 3) What are the semantics of these collections?
> > 
> > <1> a :Collection;
> >    :contains <a>;
> >    :member <b>.
> > 
> > <2> a :Container;
> >    :member <c>, <d>.
> > 
> > <3> a :Aggregation;
> >    :contains <e>, <f>.
> > 
> > <4> a :Container, :Aggregation;
> >    :contains <g>, <h>.
> > 
> > I'd recommend that if there is a conflict, then aggregation is the
> > default.  Though I don't feel strongly about it.
> > 
> > 4) Can I convert a Container to an Aggregation (or vice versa)?  It
> > would seem that it might make sense to go from Container->Aggregation
> > but not the other way, otherwise we'd have to define a bunch of rules.
> > 
> > 5) Interaction model for resource creation: I would assume the way to
> > create a resource and add it to a collection would not change for
> > Aggregation, POST representation to collection, resource created and
> > added to collection.  Right?
> > 
> > [1] - http://www.w3.org/2012/ldp/wiki/Issue-34_-_Aggregation:_simple_proposal
> > 
> > --
> > - Steve Speicher
> > 

Social Web Architect
http://bblfish.net/