Re: issue-34 example

On 20 Jan 2013, at 22:33, Andy Seaborne <andy.seaborne@epimorphics.com> wrote:

> 
> 
> 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)?


It would be useful to have a number of examples of these.

The current spec shows how a page can declaratively guide the user 
to different pages of the result just by creating a simple link type
that explains where the next page is.

That is a type of very simple guiding allowing the client to select 
the next GET.

But you are writing about input, and speaking about multi step
shopping processes which suggests POST and forms. Why does a shopping
process require a form? Because a new State has to be created, and
input requested from the user. That is some form of speech-act or rather
document-act is going on here that goes beyond simply declaring how 
things are ( saying such and such is true ).

What you want a LDPC to say is something like:

  by POSTing a graph of a certain type here <> you 
are engaging in a speech/doc act of a certain type
that will be named and referrable to later, and
that may put a certain obligation on you.

  Perhaps with a few examples as I said, one could look them
up, see if there are patterns and how they could be implemented.


> 
> 	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
>>>>> 
>>>> 
>>> 
>> 
> 

Social Web Architect
http://bblfish.net/