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

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. 

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/