W3C home > Mailing lists > Public > public-ldp-wg@w3.org > January 2014

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

From: Alexandre Bertails <bertails@w3.org>
Date: Mon, 06 Jan 2014 09:53:06 -0500
Message-ID: <52CAC352.60905@w3.org>
To: "Linked Data Platform (LDP) Working Group" <public-ldp-wg@w3.org>
Reading http://tools.ietf.org/search/rfc6906 , 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]
>
> http://www.w3.org/2012/ldp/track/issues/92
>
> 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.
>
> 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.
>
> 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).
>
>
>
>
Received on Monday, 6 January 2014 14:53:05 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 16:17:47 UTC