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

forgot to reply-all

On Sat, Jan 19, 2013 at 8:57 AM, Steve Speicher <sspeiche@gmail.com> wrote:
> On Fri, Jan 18, 2013 at 6:11 PM, Henry Story <henry.story@bblfish.net> wrote:
>>
>> On 18 Jan 2013, at 22:23, Steve Speicher <sspeiche@gmail.com> wrote:
>>
>>> 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 ?
>>
>> I should perhaps have chosen a different namespace for these, and not
>> ldp. Perhaps ldpTst or something.
>>
>> The point of having these three classes, and these two relations,
>> is just to help with clarity. These don't have to be adopted
>> officially. Having a ldp:contains and an ldp:member, and having
>> these have different rdf:domains, does not mean we cannot then make
>> them owl:sameAs some well known vocabulary later, or adopt them for
>> ldp.
>>
> One primary difference with the owl:sameAs approach is the global
> nature of that statement.  Perhaps there are cases with my specific
> application where the predicate is only a 'containment' predicate for
> the current associated container, not every and all instances.  The
> ldp:memberPredicate minimizes the scope.
>
>> I just find rdfs:member a bit confusing because it comes with a baggage
>> of semantics which is probably not what we want here, or if it is
>> we need to discover that. In any case I did not think it was a good
>> idea to bring that baggage into the discussion when discussion the
>> concept of containership, membership, and aggregations.
>>
>>
>>>
>>> 3) What are the semantics of these collections?
>>>
>>> <1> a :Collection;
>>>   :contains <a>;
>>>   :member <b>.
>>
>> That was left undecided in what I said. It may be possible for
>> a collection to exist with both, or not.
>>
>>>
>>> <2> a :Container;
>>>   :member <c>, <d>.
>>
>> member had a domain of a ldp:Aggregation. So the definition only
>> allows that if there is an intersection between ldp:Aggregation
>> and ldp:Container
>>
>
> Didn't catch the domain restriction.
>
>>>
>>> <3> a :Aggregation;
>>>   :contains <e>, <f>.
>>
>> same as above, but check the definition for :contains in
>> http://www.w3.org/2012/ldp/wiki/Issue-34_-_Aggregation:_simple_proposal
>>
>>>
>>> <4> a :Container, :Aggregation;
>>>   :contains <g>, <h>.
>>
>> you can either decide that contains can be a relation on both container and
>> Aggregation, or find a relation the is a super property of contains  to do the
>> job.
>>
>>> I'd recommend that if there is a conflict, then aggregation is the
>>> default.  Though I don't feel strongly about it.
>>
>> I had not thought through this. But as you see having the above vocabulary
>> written out does make it possible to pose those questions clearly.
>> I think one would have to work from first principles and some intuitions.
>>
>> So currently the :contains relation means that if you delete the :Container,
>> all its contents, that is after binding the ?container variable in the
>> query below with the name of your container
>>
>> SELECT ?c
>> WHERE { ?container :contains ?c }
>>
>>
>> then all the answers to the above query get deleted too.
>> This is what you'd expect say if you take a filing cabinet and say
>> throw it on the fire. The cabinet burns and so does
>> the content. That is why I think we are using the word "Container"
>> and "content"
>>
>> It is also what you'd expect if you take a file hierarchy view of a url.
>> so if you delete the "img/" container in
>>
>> http://example.co/people/joe/img/2012/22-soldiers.jpg
>>
>> then you have made it impossible to write anything after
>> http://example.co/people/joe/img/.*
>>
>> Btw we notice that if you delete a container you delete it's
>> contents but as a consequence also the members of some aggregations
>> (they suddenly won't refer to anything anymore) - and it would make
>> sense for a consistent server to delete the elements of those aggregations.
>>
>> Ok, so those are some intuitions one can build on.
>>
>>
>>>
>>> 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.
>>
>> I am not sure what you mean. Say you have a
>
> I'm not sure how to explain it much differently other than, if I have
> a ldp:Container in hand (as a client) and I want it to have
> ldp:Aggregation semantics, do I need to create a new ldp:Aggregation,
> add members from Container.   Or do I PATCH the ldp:Container with <c>
> rdf:type ldp:Aggregation?
>
>> <http://example.co/people/joe/img/> a Container.
>>
>> then you DELETE
>>
>> <http://example.co/people/joe/img/>
>>
>> and then you could have
>>
>> <http://example.co/people/joe/img/> a Aggregation.
>>
>> It seems ok. The way I am thinking it at present, as I write my server
>> is that anything that ends in a / is a Container and everything else
>> an LDPR  of which  some can be (or define) an LDPA.
>>
>>>
>>> 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?
>>
>> Is that not clear in the examples here:
>> http://www.w3.org/2012/ldp/wiki/Issue-34_-_Aggregation:_simple_proposal
>>
>> ?
>> Are you asking if you can also POST a graph to an Aggregation?
>>
>
> I'm asking if semantics are the same for POSTing to a Container.  I
> would think it would be desirable that they both would have the same
> semantics.  I can see why LDPRs would be different, it would seem odd
> that POST to Aggregation would be different than POST to Container.
>
>> If as suggested today in ISSUE-45 you can POST some RDF to a LDPR to
>> append the triples to that LDPR, then POSTing the triple
>>
>> <#ion> :member <http://bblfish.net/>
>>
>> to
>>
>> <http://localhost:9000/2013/aggReg>
>>
>> would add that triple to the <aggReg#ion> aggregation, which
>> would be a way to add content to the aggregation. Notice that you
>> don't thereby create a new resource to do a GET on.
>>
>>
>>
>>>
>>> [1] - http://www.w3.org/2012/ldp/wiki/Issue-34_-_Aggregation:_simple_proposal
>>>
>>> --
>>> - Steve Speicher
>>>
>>
>> Social Web Architect
>> http://bblfish.net/
>>
>
> --
> - Steve Speicher



-- 
- Steve

Received on Saturday, 19 January 2013 14:40:14 UTC