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

On 6 Jan 2014, at 15:53, Alexandre Bertails <> wrote:

> Reading , rel=profile looks like the perfect approach to me.
> Alexandre.
> On 01/02/2014 02:19 PM, Linked Data Platform (LDP) Working Group Issue Tracker wrote:
>> ldp-ISSUE-92 (interaction model): Change rel=type to rel=profile for client introspection of interaction model [Linked Data Platform Spec]
>> Raised by: John Arwe
>> On product: Linked Data Platform Spec
>> When we discussed issue-91, we said that rel=type is probably not the best choice, and issue-91's proposer was very open to alternatives.
>> Most RDF literates would think of rel=type uri=ldp:Resource as a Link header as equivalent semantically to content (in an RDF resource) of <s, rdf:type, ldp:Resource>.  Indeed, until we closed action-122 the spec even said these were notionally equivalent.  The defining RFC 6903 simply says that the context uri is considered to be an instance of the target uri's abstract semantic type (i.e. it's a good match for rdf:type).  There is no mention of interaction constraints being conveyed.

If you have a graph that said

  <#joe> a :Elephant .

This would tell you quite a lot about how you can interact with <#joe> .

>> 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?
So if you had a graph at http://test.example/container/ that said

 <> a ldp:Container

( either in the header or in the document )
and you copied it somewhere else to say http://moved.example/2014/
would that not have 

  <http://test.example/container/> a lpd:Container .

as a triple?

I suppose the issue is to do with moving without resolving the graph, which seems like of course very prone to 
creating bad errors.

The reall issue I think between the information in the header and in the graph, has to do with the header being 
something the server is making a statement about. ( It is server based metadata on the header ).

>> The best candidate I see in the existing relation type registry is profile (RFC 6906), which I propose we use instead of 'type'.
>> If we cannot agree to use profile, then I propose that LDP mints an extension link relation type that it owns (making it an extension implies zero registration requirements).

profile seems more specific. 

	This specification defines the 'profile' link relation type that
allows resource representations to indicate that they are following
one or more profiles.  A profile is defined not to alter the
semantics of the resource representation itself, but to allow clients
to learn about additional semantics (constraints, conventions,
extensions) that are associated with the resource representation, in
addition to those defined by the media type and possibly other


Social Web Architect

Received on Monday, 6 January 2014 15:27:51 UTC