Re: interaction with a bug-tracker LDP service

On 20/12/12 14:48, Roger Menday wrote:
>>>
>>>> Hi Roger,
>>>>
>>>> A question about this part:
>>>>
>>>>> POST to <Tracker/1;has_bugs> with "<> :content 'i am THIRD Bug!'. "
>>>>
>>>> Could <Tracker/1> be an LDP-Container or were you avoiding that for some
>>>> reason?
>>>> ------------------
>>>> ---- <http://server/Tracker/1>
>>>> <Tracker/1>
>>>>      a ldp:Container;
>>>>      ldp:membershipSubject <Tracker/1/Bugs> ;
>>>>      ldp:membershipPredicate :has_bug .
>>>>
>>>> <Tracker/1/Bugs>
>>>>      :has_bug  <Tracker/1/Bug/1> ;
>>>>      :has_bug  <Tracker/1/Bug/2> ;
>>>> ------------------
>>>
>>> hi Andy,
>>>
>>> One of the reasons why I don't quite like with this approach is that the <Tracker/1> resource is not very friendly to the *read-only* (say with SPARQL SELECT) consumer (?) We wanted something which is just regular LD, but then there is a secondary 'layer' which can be revealed to direct any interaction.
>>>
>>> Roger
>>
>> So if it didn't use ldp:membershipSubject would it be better:
>
> So, that is like example 1 in the spec (?)
> But, sometimes example 2 is necessary (as the spec explains) (?)

It does but but I don't understand it (!) because the text (5.4 HTTP 
POST) simply does not describe how this is supposed to work in this ase.

What is POST'ed to the container (when there are two link sets for 
assets and liabilities)?  The POST definition says:
     "by submitting a representation as the entity body "
but nothing about the entry (e.g. which set of links it goes in). 
Surely it's post to the link set and link set != container.

Your solution of two resources works by exposing the different between 
the container and one of it's set of links as a nameable web resource.

I don't know if I should read the spec to say that ldp:membershipSubject 
names a real LDP-R, which case we have your example.

If we have three resource types, LDP-R, LDP-C and LDP-LS (link set), all 
the issues of aggregation and containment/management go away.

If you delete a C, all it's LS and the resources linked to, go away.

If there is a LS without referring C, then it's weak aggregation.

And POST/createEntry can be targetted at the LS.

I guess a logical conclusion to ldp:membershipSubject is that having the 
triples in the container object makes less sense.  Maybe the spec isn't 
saying they are.

>
> As I see it, the difference with my proposal is that my collections contain the *Links*.
>
> ?

Thank for the explanation  - I'm trying to understand your choices and 
the spec.

It could be the LDP-C ldp:membershipSubject example is describing two 
resources - http://example.org/netWorth/nw1 is a real, existent LDP-R 
that is a link set.

	Andy
>
> Roger
>
>
>>
>> -----------------
>> ---- <http://server/Tracker/1>
>> <Tracker/1>
>>       a ldp:Container;
>>       ldp:membershipPredicate :has_bug .
>>       :has_bug  <Tracker/1/Bug/1> ;
>>       :has_bug  <Tracker/1/Bug/2> ;
>>       .
>> -----------------
>>
>> (section 5.2.4)
>>
>> 	Andy
>>
>>>
>>>>
>>>> then
>>>>
>>>>     POST to <Tracker/1> with "<> :content 'i am THIRD Bug!'. "
>>>>
>>>> and get back
>>>>
>>>>     Location: <Tracker/1Bug/3>
>>>>
>>>> in the response.
>>>>
>>>> 	Andy
>>>>
>>>>
>>>> On 20/12/12 10:53, Roger Menday wrote:
>>>>> hi
>>>>>
>>>>> I would like the following to be considered alongside other recent proposals.
>>>>>
>>>>> I will illustrate the concepts with the bug-tracker example, i.e. There is a Tracker. It contains Bugs. A Bug has content, and can also be linked to other :related Bugs.
>>>>>
>>>>> eg.
>>>>>
>>>>> <Tracker/1>
>>>>>      :has_bug <Tracker/1/Bug/1>, <Tracker/1/Bug/2> ;
>>>>>      ldp:link_collection <Tracker/1;has_bug> .
>>>>>
>>>>> De-referencing the first Bug.
>>>>>
>>>>> <Tracker/1/Bug/1>
>>>>>      :related <Tracker/1/Bug/2> ;
>>>>>      :content "i am Bug!" .
>>>>>      ldp:link_collection <Tracker/1/Bug/1;related> <Tracker/1/Bug/1;content> .
>>>>>
>>>>> The above looks like readable LD, can be queried normally, etc .. The ldp:link_collection triple is the indication that this is writable (with LDP) LD.
>>>>>
>>>>> Starting with the <Tracker/1> resource, I will first create a new Bug, and then link (using :related) this Bug to another one.
>>>>>
>>>>> The <Tracker/1> resource links to its "link collection" resources.
>>>>> In this case <Tracker/1;has_bug> collection is all its :has_bug links.
>>>>> It is an POSTable endpoint which appends to the link collection.
>>>>> It advertises which properties should be supplied to seed this process.
>>>>> In this case, :content and :related (optionally)
>>>>>
>>>>> POST to <Tracker/1;has_bugs> with "<> :content 'i am THIRD Bug!'. "
>>>>>
>>>>> In this case, the server creates a new resource and then links it.
>>>>> Here is the new resource.
>>>>>
>>>>> <Tracker/1/Bug/3>
>>>>>      :content "i am THIRD Bug!" .
>>>>>      ldp:collection_set <Tracker/1/Bug/3;related> <Tracker/1/Bug/3;content> .
>>>>>
>>>>> Say then, I want to link <Tracker/1/Bug/3> to another (existing) resource.
>>>>>
>>>>> The <Tracker/1/Bug/3;related> collection represents all the :related links.
>>>>> I can discover that it requires a ldp:link property to seed the process.
>>>>>
>>>>> POST to <Tracker/1/Bug/3;related> with "<> ldp:link <Tracker/1/Bug/1> ."
>>>>>
>>>>> In this case, the server links two existing resources.
>>>>> This is discoverable, directed update.
>>>>>
>>>>> The server knows which predicates will be linking to 'progeny' resources, and which predicates are links to other, existing resources. It can direct interaction accordingly. But, the mechanism is the same for the composition or aggregation.
>>>>>
>>>>> Furthermore, the link_collections, can split into pages and linked for enumeration purposes.
>>>>>
>>>>> So, this is an outline of an approach to aggregation, along with ideas about creation, discovery, update, paging, etc .. I would like do a second scenario - a simple lightbulb on/off service next. I hope there is interest in that.
>>>>>
>>>>> regards,
>>>>> Roger
>>>>>
>>>>
>>>
>>
>

Received on Thursday, 20 December 2012 15:35:18 UTC