Re: ISSUE-37: the Graph and Links model

On 14/01/13 08:15, Roger Menday wrote:
>
> hi Andy,
>
>>>
>>> Although I wouldn't call it the "general case". I would call it
>>> the "unconstrained case".
>>>
>>> Anyway, I think that the case of arbitrary graph evolution must
>>> also be server directed.

>> After-all, it is the server that needs
>>> to approve that it able to manage an arbitrarily evolving graph
>>> (not least because a LDP server-side might not be built on top of
>>> a triple store).
>>
>> Why does "on top a triple store" matter?
>
> 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?

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

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

> 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,
>>>>>>>>
>>>>>>>> dret.
>>>>>>>>
>>>>
>>>
>>
>

Received on Monday, 14 January 2013 09:34:57 UTC