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

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