Re: rel=type or rel=profile, issue 92

* Henry Story <henry.story@bblfish.net> [2014-01-17 12:12+0100]
> 
> On 17 Jan 2014, at 01:00, Eric Prud'hommeaux <eric@w3.org> wrote:
> 
> > On Jan 15, 2014 7:56 PM, "Kingsley Idehen" <kidehen@openlinksw.com> wrote:
> > >
> > > On 1/15/14 10:06 AM, Henry Story wrote:
> > >>
> > >> In short: the argument that rdf:type is problematic does not hold.
> > >
> > > +1
> > >
> > > rdf:type is only problematic if we aren't using RDF [1] at all. We are either using RDF or we aren't.
> > 
> > We are, or at least were, taking about  protocol headers, i.e. HTTP, not RDF. The convention in HTTP is to use rel=profile for labeling the interaction model.
> 
> So we are progressing here. 
> 
> The protocol headers, contain information. All information can be expressed in RDF. So we can 
> express this information in RDF. This then allows us to reason more carefully about these things.  
> This is especially clear with the the Web Linking header of rfc 5988, which allows one to specify
> any subject, any type of relation, and any object of the relation.
> 
> Having then established that rdf:type is not a problem [1], we can now look if there is a better relation 
> to be used.
> 
> the rel=profile relation is defined in the informational rfc 6906
> http://tools.ietf.org/search/rfc6906
> 
> Here is one passage I have extracted from the above RFC
> 
> [[
>    The concept of a profile has no strict definition on the Internet or
>    on the web.  For the purpose of this specification, a profile can be
>    described as additional semantics that can be used to process a
>    resource representation, such as constraints, conventions,
>    extensions, or any other aspects that do not alter the basic media
>    type semantics.  A profile MUST NOT change the semantics of the
>    resource representation when processed without profile knowledge, so
>    that clients both with and without knowledge of a profiled resource
>    can safely use the same representation.  While this specification
>    associates profiles with resource representations, creators and users
>    of profiles MAY define and manage them in a way that allows them to
>    be used across media types; thus, they could be associated with a
>    resource, independent of their representations (i.e., using the same
>    profile URI for different media types).  However, such a design is
>    outside of the scope of this specification, and clients SHOULD treat
>    profiles as being associated with a resource representation.
> ]]
> 
> This is quite a specific relation. It speaks of 
> 
>   • adding additional semantics to process a resource representation
>   • that these semantics should not alter the basic media type semantics of the content
> 
> These two requirements seem quite contradictory with respect to RDF. It is not clear at all
> what additional semantics to process RDF would be, especially if these are not meant to alter
> the semantics of RDF serialisations. 

Your excerpts above are perfectly consistent with the convention of
using a particular rel to express the interaction model. The are also
consistent with the laudable goal of not conflating an objects's
intrinsic data properties with the interface offered for that object.

This is critical in systems that permit only one type assertion, such
as a media type, but also applies to systems with n types such as RDF.
It's semantically much clearer to use a property to identify a media
type that to mix it in with the types. Querying for the property is
trivial while sorting out the types that define an interaction model
introduces unnecessary complexity.

Apart from how we would best model types vs. interaction models, we
are good netizens who use HTTP headers as the are intended, and
rel=profile is intended to communicate the interaction model.


> Further down this is made clearer yet again:
> 
> [[
>    A media type defines both the semantics and the serialization of a
>    specific type of content.  In many cases, media types have some
>    built-in extensibility or openness, so that specific instances of the
>    media type can layer additional semantics on top of the media type's
>    foundation.  In this case, a profile is the appropriate mechanism to
>    signal that the original semantics and processing model of the media
>    type still apply, but that an additional processing model can be used
>    to extract additional semantics.  This is in contrast to a new media
>    type that, instead of just adding processing rules and semantics
>    defines a complete set of processing rules and semantics in most
>    cases. As an example, XHTML is not a profile of XML but a new media
>    type because it introduces a complete new perspective of the
>    underlying XML structures, and from the XHTML point of view, exposing
>    the raw XML is not all that useful for clients. 
> ]]
> 
> So I really don't see how the profile here has anything to do with what we have been discussing
> here, namely the interaction constraints that a resource that is an LDPC has. Being an LDPC has
> nothing to do with the interpretation of the representation returned by the LDPC. An LDPC is
> a resource that supports certain types of interactions: GET, POST, etc as described by the
> spec. These are interactions types. Profiles is something completely different.
> 
> Henry
> 
> 
> [1] http://lists.w3.org/Archives/Public/public-ldp-wg/2014Jan/0049.html
>   
> 
> Social Web Architect
> http://bblfish.net/
> 

-- 
-ericP

office: +1.617.599.3509
mobile: +33.6.80.80.35.59

(eric@w3.org)
Feel free to forward this message to any list for any purpose other than
email address distribution.

There are subtle nuances encoded in font variation and clever layout
which can only be seen by printing this message on high-clay paper.

Received on Friday, 17 January 2014 18:45:57 UTC