Re: Getting to closure on the remaining issues - issue-92

On 25 Jan 2014, at 09:21, Eric Prud'hommeaux <eric@w3.org> wrote:

> * Henry Story <henry.story@bblfish.net> [2014-01-25 09:07+0100]
>> 
>> On 25 Jan 2014, at 08:01, Eric Prud'hommeaux <eric@w3.org> wrote:
>> 
>>> On Jan 24, 2014 7:37 PM, "Henry Story" <henry.story@bblfish.net> wrote:
>>>> 
>>>> 
>>>> On 24 Jan 2013, Eric Prud'hommeaux wrote as shown in the archive
>>>> http://lists.w3.org/Archives/Public/public-ldp-wg/2014Jan/0121.html
>>>>> On 24 Jan 2014, at 18:38, Henry Story <henry.story@bblfish.net> wrote:
>>>>> 
>>>>>> On 24 Jan 2014, at 18:14, Alexandre Bertails <bertails@w3.org> wrote:
>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>> In plain English: ldp:Container happens to be a class that can be used
>>>>>>>>>>> to denote the Container interaction model when used with
>>>>>>>>>>> rel=profile. What's wrong in that sentence?
>>>>>>>>>> 
>>>>>>>>>> What does it denote when it is not used with rel=profile?
>>>>>>>>> 
>>>>>>>>> Then the behavior is not defined. It's ok because we're only
>>>>>>>>> interested in defining what it means when we use it with rel=profile,
>>>>>>>>> or when you use it as a class.
>>>>>>>> 
>>>>>>>> A URI refers to one thing. This is not a question of behaviour. That
>>>>>>>> is how URIs are defined.
>>>>>>>> 
>>>>>>>> [[
>>>>>>>>  A Uniform Resource Identifier (URI) provides a simple and extensible
>>>>>>>>  means for identifying a resource.
>>>>>>>> ]]
>>>>>>> 
>>>>>>> I gave you the one declarative and universal meaning for
>>>>>>> ldp:Container: it denotes the LDPC interaction model when used with
>>>>>>> rel=profile, you're on your own for other rels.
>>>>>>> 
>>>>>>> Does this introduce any contradiction with anything else?
>>>>>> 
>>>>>> yes, there is no such thing as "denoting something when used with ..."
>>>>>> Have you got a definition of that somewhere?
>>>>>> 
>>>>>> Some further supporting evidence from RDF Semantics:
>>>>>> 
>>>>>> [[ http://www.w3.org/TR/2004/REC-rdf-mt-20040210/#urisandlit
>>>>>> 
>>>>>> This document does not take any position on the way that URI references may be composed from other expressions, e.g. from relative URIs or QNames; the semantics simply assumes that such lexical issues have been resolved in some way that is globally coherent, so that a single URI reference can be taken to have the same meaning wherever it occurs.
>>>>>> ]]
>>>>>> 
>>>>>> So imagine you have some other relation that is like profile but narrower, say an ldp:profile
>>>>>> then ldp:Container would have to still refer to the same thing in the relation below:
>>>>>> 
>>>>>> <> ldp:profile ldp:Container .
>>>>>> 
>>>>>> which if we translate it using your grue like definition would come to
>>>>>> 
>>>>>> <> is related by the ldp:profile relation to the thing denoting the ldp interaction if related by rel=profile,
>>>>>>    but you're out of luck for other rels.
>>>>>> 
>>>>>> so here it would be
>>>>>> 
>>>>>> <> related by ldp:profile to we know not what.
>>>>>> 
>>>>>> What if someone then wants to write a vocabulary that describes interaction models?
>>>>>> Say they want to say of an interaction model that it supports POST and that this creates
>>>>>> new resources in some way,....
>>>>>> 
>>>>>> ldp:Container interaction:methodSupported "GET", "PUT", "POST", "PATCH" .
>>>>>> 
>>>>>> following the above reasoning we have no idea what ldp:Container is referring to above.
>>>>>> 
>>>>>> Clearly this would go against all the semantic web reasoning layers that have been agreed
>>>>>> to in various groups at the W3C.
>>>>>> 
>>>>>> I am surprised you even think of presenting this as an argument!
>>>>>> You have just helped me  thump another stake in the heart
>>>>>> of this rel=profile time consuming vampire .
>>>>> 
>>>>> And I am surprised that you think it's reasonable to use the same identifier for a graph representing an LDP container AND the protocol for interacting with it.
>>>> 
>>>> 
>>>> You mean that <http://example/> in say { <http://example> a ldp:Container . } would refer to a Graph?
>>>> 
>>>> Only if the Graph can be a temporal thing that can change over time, which is not the
>>>> strict definition of Graph in the RDF specs.
>>>> 
>>>> The representation returned by <http://example/> is a Graph, but you must not
>>>> confuse the representation with the resource. The resource is something that
>>>> has an interaction model, and that can change over time, whilst keeping its
>>>> identity of course  :-) .
>>> 
>>> Very true. What do you propose as a stable identifier for the LDP1.0 interaction model as distinct from the resource itself?
>>> 
>> ldp:Container should do . It  is a class whose intension sets the criteria for selecting the members 
>> both actual and non actual that belong to it. The definition is provided by the LDP spec. 
> 
> So then we are back to not being able to use LDP containers with a
> different interaction model, e.g. SPARQL.

Good question. I am surprised this was not brought up earlier. 

I am not sure what you mean by a SPARQL as in interaction model.
Let's imagine you mean that such an LDPC should support the HTTP
SEARCH method (as initially proposed 
   http://www.w3.org/Protocols/HTTP/Methods.html )
and that this could be done by sending a SPARQL body.

Then if those resources all behave in all other respects as an LDPC then
those resources are ldp:Containers. If you want to be more specific about those
that also support SEARCH  then you can create a subclass of ldp:Container

ldp:SContainer rdfs:subClassOf ldp:Container;
    rdfs:comment "the set of ldp:Containers that also support the SEARCH method ..." .

Then you could write

 <> a ldp:SContainer;
    ldp:contains <m1>, <m2>, <m3> .

Btw, just to show that I am not making this up here but that I have been 
quite consistent with this view you can check my Issue-50 on intuitive containers
  http://lists.w3.org/Archives/Public/public-ldp-wg/2013Feb/0134.html

Btw, if you look at the discussions along these lines subclassing has been
a constant theme throughout.


Anyway, SEARCH is not such a bad idea. Perhaps we could add it to our spec now :-)

> 
> 
>> Being a member of the ldp:Container class is to behave the way the spec says those resources 
>> should behave. On a GET they return a Graph, on a POST they create something, etc...
>> 
>> Hence there is no problem with 
>> 
>> <> a ldp:Container .
>> 
>> So you can also have something like
>> 
>> <> ldp:interaction ldp:Container .
>> 
>> but that would just end up implying the first anyway.
>> 
>> 
>> Henry
>>>> The representation returned is something that can
>>>> be interpreted in terms of a graph, and whose content describes a set of
>>>> possibilities. In the case of { <> a ldp:Container }, the graph returned
>>>> as the representation describes the resource as being one of the objects which
>>>> can be interacted with according to the ldp spec.
>>>> 
>>>> This is just basic REST: Representation of State Transfer. The representation is
>>>> a represntation of a _Resource_ referred to by a URI.
>>>> 
>>>> Henry
>>>> 
>>>> 
>>>>>> 
>>>>>>  Henry
>>>>>> 
>>>>>> 
>>>>>> Social Web Architect
>>>>>> http://bblfish.net/
>>>>>> 
>>>>> 
>>>>> 
>> 
>> Social Web Architect
>> http://bblfish.net/
>> 
> 
> -- 
> -ericP
> 
> office: +1.617.599.3509
> mobile: +33.6.80.80.35.59
> 
> (eric@w3.org)
> Feel free to forward this message to any list for any purpose other than
> email address distribution.
> 
> There are subtle nuances encoded in font variation and clever layout
> which can only be seen by printing this message on high-clay paper.

Social Web Architect
http://bblfish.net/

Received on Saturday, 25 January 2014 10:02:05 UTC