Re: issue-34 example

On 20/01/13 20:59, Roger Menday wrote:
>
> hi Andy,
>
>>> It seems that we will never see eye-to-eye on this :) I just
>>> think that what you want to do with LDP, is different from what I
>>> want to do.
>>>
>>> I want solutions where servers which guide my clients through a
>>> service. If it is "unfriendly week", the hypermedia directing
>>> linking with the :friend predicate shouldn't be there. Your
>>> solution is essentially allowing any data to be added.
>>>
>>> Would you agree ?
>>
>> I agree that I want LDP to support adding arbitrary data.  May not
>> be the only usage and some implementations may not allow the
>> opertation (thay can always refuse anything).
>
> Well, the server can always refuse something which would otherwise
> put the system into an 'illegal' state - but, this isn't the most
> helpful way of going about things.

Where is the pre-condition / guidance to the operation?

> btw: In the 'graph and links model', a resource might either be
> liberal about which other properties it accepts (or not). This then
> is a model which covers both arbitrary and constrained data
> interaction.
>
>>>
>>> I hope we can support both in LDP (I think we can).
>>
>> I hope so - I'm having difficulty seeing what state manipulations
>> you have in mind.  Do you have a concrete example?
>
> Yes ! our LDP example - the Bug tracker.

"where servers which guide my clients through a service."

What do you consider as guiding?

I read "guiding" as, for example, the return indicates what the client 
can do next (in the same way that sending back a form on a multi step 
shopping process indicates the next steps).  How does the bug tracker 
guide the client if it is not just constrains on input (roughly, 
documentation)?

	Andy

> It seems that most (almost all) applications have some constraints on
> how a graph may be evolved by LDP. A concrete, simple example started
> this email thread; friends and enemies - if I want to add a new arc
> to a Person, called :friend, it is only allowed to link to another
> person, etc etc ...
>
> I believe you will see similar constraints in pretty much any "Web
> API" or "REST API" around on the web.
>
> Roger
>
>> Isn't the only state is the RDF of a LDP-R?  A unique
>> characteristic here is that an LDP has no hidden/implicit state?
>
>
>
>>
>> Andy
>>
>>>
>>> Roger
>>>
>>>
>>>> POST, as it's simply additional triples:
>>>>
>>>> <Person/1> :friend <Person/4> .
>>>>
>>>> This follows from "Extending a database through an append
>>>> operation." (RFC 2616)
>>>>
>>>> (it would be valuable to be explicit that POST to LDP-R is add
>>>> triples)
>>>>
>>>> Andy
>>>>
>>>> On 18/01/13 00:25, Arnaud Le Hors wrote:
>>>>> Hi Roger,
>>>>>
>>>>> I have to admit not to understand how your example justifies
>>>>> adding anything to LDP.
>>>>>
>>>>> The spec as it stands allows you to update resources via PUT.
>>>>> Why isn't it enough to PUT the new representation with the
>>>>> added Person? Why does your resource have to be anything
>>>>> special to the server rather than just another RDF resource
>>>>> which happens to contain references to a bunch of resources
>>>>> in a totally standard RDF fashion? -- Arnaud  Le Hors -
>>>>> Software Standards Architect - IBM Software Group
>>>>>
>>>>>
>>>>> Roger Menday <roger.menday@uk.fujitsu.com> wrote on
>>>>> 01/17/2013 02:31:18 PM:
>>>>>
>>>>>> From: Roger Menday <roger.menday@uk.fujitsu.com> To:
>>>>>> "public-ldp-wg@w3.org Group" <public-ldp-wg@w3.org>, Date:
>>>>>> 01/17/2013 02:32 PM Subject: issue-34 example
>>>>>>
>>>>>>
>>>>>> Given the following LD.
>>>>>>
>>>>>> <Person/1> :friend <Person/7>, <Person/9> :enemy
>>>>>> <Person/6>
>>>>>>
>>>>>> Issue-34 says it needs a simple way of linking a new
>>>>>> friend (<Person/4>), to end up with
>>>>>>
>>>>>> <Person/1> :friend <Person/7>, <Person/9>, <Person/4>
>>>>>> :enemy <Person/6>
>>>>>>
>>>>>> ?
>>>>>>
>>>>>> So, I believe that aggregation is an essential piece for
>>>>>> lDP.
>>>>>>
>>>>>> regards, Roger
>>>>
>>>
>>
>

Received on Sunday, 20 January 2013 21:34:16 UTC