Re: ldp-ISSUE-92 (interaction model): Change rel=type to rel=profile for client introspection of interaction model [Linked Data Platform Spec]

On 7 Jan 2014, at 15:58, John Arwe <johnarwe@us.ibm.com> wrote:

> > If you have a graph that said
> > 
> >   <#joe> a :Elephant .
> > 
> > This would tell you quite a lot about how you can interact with <#joe> .
> 
> Ok, I'll bite.  What exactly does the rdf:type statement tell *code* about how it can interact with <#joe>? 

Say you have a robot that can walk around, and that knows that <#joe> is an elephant, then it will know a lot of things
that are true of Elephants in general. IT will know that it has a trump, and that it walks around on 4 legs, that
if it is older it has a certain size, etc... It will know that it eats, that is has good memory usually, etc. Those
are all kinds of constraints on how the robot can interact with the elephant. For example it is quite different than how it 
would interact with <#jimmy> a cricket. With an elephant the human sized robot might have a chance to meet it head on. 
With a bacteria a cricket it might have to look in completely different places.


> > >> By Alexandre's own example (making a backup of an LDPC/LDPR), the
> > >> backup is just a document (it has the same RDF content, including 
> > >> the same rdf:type(s), but a different interaction model), not an LDPC or LDPR.
> > If you copied the graph, would you not have the URLs pointing to the
> > original URL? 
> 
> Right.  The triples in my head were different (but mine were incorrect). 
> 
> > I suppose the issue is to do with moving without resolving the 
> > graph, which seems like of course very prone to 
> > creating bad errors.
> 
> Right.  And if you don't resolve the URIs in the graph, it's probably true that you don't have an RDF graph (although I haven't checked the formal definition), you have a representation that *could be converted into an RDF graph* if given a base URI.  I'm not interested in breaking new ground on how to do that movement safely/sanely. 
> 
> > profile seems more specific. 
> 
> More specific (than type) could be good or bad in your view, I'm not sure which.   
> As I related on a call, I did consult with the RFC author first and he thought profile was a reasonable fit for our use case.  To paraphrase him, profile is intended as a lightweight way to refine the definition of existing media type(s) when you don't want to register a new media type.  As Alexandre has said, defining a new media type would be the usual way to do what LDP is doing. 

But an LDPC has nothing to do with media types. LDPC or LDPRs are resource, that can produce representations. Media types are not specifications 
of interactions, they are specifications of syntaxes. In the real world a media type would be like asking a book what language it is in. If it is
in German or French or Japanese. This is important to how you can read the book. The LDPR/LDPC distinction has nothing to do with that. It has
to do with say if the type of book you have: eg: is it a book, is it electronic, is it made of stone, etc... If made of stone, you need to use a chisel
to interact with it. If it is made of paper, a pencil will do.  

> 
> If I read "more specific" to mean "-1 that", do you feel that rel=type is The Right Choice (anything else -1), would you prefer we mint our own URI (which is completely allowed by 5988), or what?  Seems like in the ideal case we use the list to find apparent consensus and then vote on the call to confirm that.  Otherwise we'll be here until 10 minutes after the sun goes nova.

rel=type is the status quo. We have had that since the beginning. We have always had 

<> a ldp:Container .


So I don't see any good reason to change.

> 
> Best Regards, John
> 
> Voice US 845-435-9470  BluePages 
> Tivoli OSLC Lead - Show me the Scenario 
> 
> 

Social Web Architect
http://bblfish.net/

Received on Tuesday, 7 January 2014 17:14:54 UTC