Re: ISSUE-37: the Graph and Links model

Andy, 

thanks for your email. I'm very keen to understand your viewpoint.

>> Put another way: if a LDP service happens to be built on top of a
>> table model (which can't easy accommodate arbitrary data), then it
>> shouldn't have to accept arbitrary inserts to be able to call itself
>> LDP compliant, particularly when the application needs constrained
>> interaction.
> 
> I still don't understand why it (evolving the graph) "must be server 
> directed".   Isn't this choice about the application on top of the spec, 
> which may lead to a specific implementation?

Well, when it is client directed it is basically a free-for-all (?) 
... and the client doesn't get the REST-effects.

> 
>>> In fact, it seems at odds with containers, server or client.
>> 
>> can you explain what exactly is at odds with containers ?
> 
> A system built with the whole platform as a single triple stores don't 
> need containers to manage creation of resources

well, inside the protocol the containers are still essential, IMO. 

> - simple put a triple 
> into the store using the URI.  


> Ditto if a LDP that is a KW store 
> URI->graph document.

> I see containers as a useful application design pattern (bug report 
> creation etc) and a pattern of resource management.
> 
>> 
>>> 
>>> If the client can PUT to a new resource, it can create new LDP-R.
>>> 
>> 
>> Well ok, but what if the client *can't* PUT ? (because the server
>> rejects the operation). The result is that they cannot create a
>> LDP-R, I suppose.
> 
> A server (I'd prefer to say the application the server is implementing) 
> may reject anything just because it wants to.  Restricting by vocabulary 
> is a possibility.

actually, I see that as a kind of server direction. 

But, if the server knows that there are certain things it likes and others that it doesn't, then this should be used to guide how the client interacts with the system.

> 
>> 
>> Or are you saying that they always can make this create successfully
>> ?
>> 
>> However, don't you think it is more efficient and useful when the
>> server directs that interaction ?
> 
> I don't see why it is more efficient - maybe you could give a concrete 
> example.

For me this is the difference between a "application access protocol" or a "data access protocol" (or REST vs. CRUD). 

I wonder what others think ?

Roger

> 
>> What I am saying is that if the application requires arbitrary
>> creation, then reflect this in the resources (with very liberal
>> affordances in that case).
>> 
>> Roger
>> 
>>> Andy
>>> 
>>>> 
>>>> Roger
>>>> 
>>>>> All the best, Ashok
>>>>> 
>>>>> On 1/13/2013 1:08 PM, Roger Menday wrote:
>>>>>> hi Ashok,
>>>>>> 
>>>>>>> Can a client create collections from this root resource?
>>>>>> Yes, when directed in the application.
>>>>>> 
>>>>>> I would like to ask a question back to you. Are you mainly
>>>>>> thinking of 'freestyle' applications (where a client can
>>>>>> evolve the graph however they please), or more constrained
>>>>>> applications ?
>>>>>> 
>>>>>> I don't ignore the freestyle kind, but, most of my scenario's
>>>>>> are the more  constrained variety.
>>>>>> 
>>>>>> For example, in the Bug tracker scenario, if a Bug is to have
>>>>>> an associated collection of Comment resources, this is
>>>>>> something that the server sets-up for the client to follow
>>>>>> and interact with, i.e. when a Bug resource is created, the
>>>>>> server also provides the means for a client to discover that
>>>>>> Comments can be created.
>>>>>> 
>>>>>> regards, Roger
>>>>>> 
>>>>>>> All the best, Ashok
>>>>>> 
>>>>>>> On 1/12/2013 10:22 AM, Roger Menday wrote:
>>>>>>>> hello there
>>>>>>>> 
>>>>>>>>>> 4. "Does each LDP model have/need a service document?
>>>>>>>>>> If yes, perhaps collections could be created by PUT
>>>>>>>>>> on the service document?"
>>>>>>>>>> 
>>>>>>>>>> I don't see a need for service documents.
>>>>>>>>> apart from the terminology "service document", i am
>>>>>>>>> wondering how you are envisioning interactions with
>>>>>>>>> the server for collection management, when you don't
>>>>>>>>> have a resource that allows you to provide interaction
>>>>>>>>> affordances for things such as, for example, the
>>>>>>>>> creation of collections?
>>>>>>>> the server provides a well-known 'root' resource from
>>>>>>>> which the interaction affordances, existing resources,
>>>>>>>> etc. can be discovered. just like on the HTML web.
>>>>>>>> 
>>>>>>>> Roger
>>>>>>>> 
>>>>>>>>> thanks and cheers,
>> 
>