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:29 PM, Kingsley Idehen wrote:
> 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 

Typo fixes and new reference links:

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 URI resolve to a document 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 
conveys by way of its semantics.

The semantics of "whole and parts" relations are no different to 
"containers and the things they contain" relations. A collection may 
have "part and whole" and "loosely associated" or <link ="related"/>  
relations that as the basis for its associations with other items etc..

Links:


1. http://www.w3.org/2001/sw/BestPractices/OEP/SimplePartWhole/ -- 
Simple part-whole relations in OWL Ontologies
2. http://www.w3.org/2001/sw/BestPractices/OEP/SimplePartWhole/part.owl 
-- rdf/xml representation of the ontology
3. 
http://linkeddata.uriburner.com/about/html/http/www.w3.org/2001/sw/BestPractices/OEP/SimplePartWhole/part.owl 
-- HTML view of the ontology.

-- 

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