Re: Proposal to close ISSUE-59 (recursive-delete): Reconsider usage of Aggregate/Composite construct to get predictable container delete behavior

On 4/19/13 6:14 PM, Arnaud Le Hors wrote:
> Please, let's not rehash the same debate over and over.
>
> From what I understand we have two opposing views of the world.
>
> On one side we have people who think that all links are created equal 
> and the client/server interaction is solely dependent on the semantic 
> associated with the predicates used to link two resources. The client 
> will know from the associated semantic whether a link is worth 
> following or not, and what following that link means.
>
> On the other side we have people who think not all links are the same 
> and the protocol needs to differentiate between those that primarily 
> serve as identifiers and those that are there as navigational links. 
> The idea being that while the former can be followed for informational 
> purpose they have no purpose in the client/server interaction. In this 
> model client need a way to distinguish between the two types of links 
> so that they don't get lost/sidetracked following links that are not 
> part of the protocol/navigation model.
>
> I fear that putting labels on these groups of people will set people 
> off but I would say that the RDF/Linked Data (e.g., Henry, Kingsley) 
> fall in the first category while the REST people (e.g., Erik) fall in 
> the second one. I don't know whether there is a way to reconcile these 
> two views or not but I'm sure hammering the same arguments over and 
> over isn't going to make a difference other than wasting more 
> bandwidth and mailbox storage.
>
> So unless someone has a suggestion on how to converge, please, let's 
> put this topic to rest.

How?

I've tried but it just keeps on looping.

Erik wants a media type (I put application/x-turtle forth as a compromise).
Those of us that have actually built and deployed RDF based Linked Data 
solutions don't see the need for the Turtle media type to be forked to 
defined any further if its definition clearly address the fact that:

1. it is a media type associated with RDF
2. a URIs resolve to documents that describe said URI's referent i.e., a 
URI resolves to its meaning.

If a de-referencable URI doesn't resolve to its meaning, then to what 
does it resolve?

We are being challenged by the fundamental interpretation of what it 
means for a link to denote a relation. Ditto what a relation actually 
coneys by way of its semantics.

Kingsley
>
> Thanks.
> --
> Arnaud  Le Hors - Software Standards Architect - IBM Software Group
>
>
> Kingsley Idehen <kidehen@openlinksw.com> wrote on 04/19/2013 02:39:54 PM:
>
> > From: Kingsley Idehen <kidehen@openlinksw.com>
> > To: public-ldp-wg@w3.org,
> > Date: 04/19/2013 02:40 PM
> > Subject: Re: Proposal to close ISSUE-59 (recursive-delete):
> > Reconsider usage   of Aggregate/Composite construct to get
> > predictable container delete behavior
> >
> > On 4/19/13 5:21 PM, Wilde, Erik wrote:
> > > hello kinsgley.
> > >
> > > On 2013-04-19 12:23 , "Kingsley Idehen" <kidehen@openlinksw.com> 
> wrote:
> > >>     A directory has a *containment* relation with resources.
> > >>     A directory also has symbolic link (so to speak) relation with
> > >>     resources.
> > >>     The relations above are inescapable. To ignore them is to 
> introduce
> > >>     regression or undue limitations. Henry explained the logic with
> > >>     clarity.
> > > it all depends on use cases, at least for the REST side of things. if
> > > you're just browsing, you don't care about the difference between 
> a file,
> > > a hard link, and a soft link.
> >
> > Correct.
> >
> > >   once you start doing other things (such as
> > > being able to add something as content, hard link, or soft link; or
> > > removing something and understanding whether you're just unlinking or
> > > actually deleting it), that difference becomes relevant and has to be
> > > exposed.
> >
> > Yes, and it is exposed by the semantics of the relation, as outlined in
> > the ontology by Henry.
> >
> >
> > > typically in REST, you start with use cases, design stateless
> > > hypermedia-based application flows, make sure you have the interaction
> > > data model and interaction affordances in place, and then you have a
> > > working design (for that use case).
> >
> > Yes, and with RDF based Linked Data there is a fundamental affordance
> > called: machine-readable and comprehensible relation semantics. The
> > schema is logic i.e., First-order logic. The aformentioned 
> affordance is
> > intrinsic to RDF based Linked Data.
> >
> > You can look at it this way:
> >
> > RDF based Linked Data delivers an affordance that enables URLs denote
> > Web documents that describe entities (which may or may not be Web
> > accessible) via URIs i.e, said URIs are denoted by URIs. If you don't
> > agree with this affordance then you simply have to toss RDF based 
> Linked
> > Data  out of the window re. this entire effort.  To call such an effort
> > the "Linked Data Platform" and then also claim it is based on RDF,  and
> > in line with TimBL's Linked Data meme etc.., becomes a wasteful
> > distortion or reality.
> >
> > A Generic Linked Platform is not an RDF based Linked Data Platform. The
> > affordances aren't isomorphic.
> >
> > I suspect Henry and others are exhausted, hence their silence re. this
> > permathread.
> > >
> > > cheers,
> > >
> > > dret.
> > >
> > >
> > >
> >
> >
> > --
> >
> > Regards,
> >
> > Kingsley Idehen
> > Founder & CEO
> > OpenLink Software
> > Company Web: http://www.openlinksw.com <http://www.openlinksw.com/>
> > Personal Weblog: http://www.openlinksw.com/blog/~kidehen 
> <http://www.openlinksw.com/blog/%7Ekidehen>
> > Twitter/Identi.ca handle: @kidehen
> > Google+ Profile: https://plus.google.com/112399767740508618350/about
> > LinkedIn Profile: http://www.linkedin.com/in/kidehen
> >
> >
> >
> >
> >


-- 

Regards,

Kingsley Idehen	
Founder & CEO
OpenLink Software
Company Web: http://www.openlinksw.com
Personal Weblog: http://www.openlinksw.com/blog/~kidehen
Twitter/Identi.ca handle: @kidehen
Google+ Profile: https://plus.google.com/112399767740508618350/about
LinkedIn Profile: http://www.linkedin.com/in/kidehen