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

On 17 Jan 2014, at 19:45, Eric Prud'hommeaux <eric@w3.org> wrote:

> * 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.

Yes, you can use "a particular" rel to express an interaction model.  I agree,
since I believe that the set of ldp:Containers are those resources with which
one can interact in ways defined by the LDP spec, i.e. those resources which
are in the rdf:type relation to rdf:Container.

But the rel proposed is the "profile" rel from the RFC I quote from, and it  makes
no mention of interaction models as far as I can see. Can you perhaps make
clear how you come to the conclusion that there is? Presumably the definition of 
"profile" should  not just not be inconsistent with there being a relation that
relates something to an interaction model, but should also be one that does
say something about interaction models.

> 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.

I don't know what system you mean that permits only one type assertion.
Surely it can't be HTTP since it allows the Link header which allows rdf:type
assertions.... ?

I think one should not take the "type" in media type too seriously. Think of it
as a relation from an object to a string. As I mentioned previously you 
can always create a new type from such a relation. Lets says we have the
mimeType relation. Then we can create the HTML class of objects with the
following OWL:

:HTML a owl:Class;
   owl:equivalentClass [ a owl:Restriction;
                 owl:hasValue "text/html";
                 owl:onProperty :mimeType ] .

which in SPARQL would amount to something like the following
rule

CONSTRUCT { ?representation a :HTML }
WHERE {
 ?representation :mimeType "text/html" .
}



> It's semantically much clearer to use a property to identify a media
> type than to mix it in with the types.

Psychologically it may be more natural, but you get equivalences quite 
easily. 

> Querying for the property is
> trivial while sorting out the types that define an interaction model
> introduces unnecessary complexity.

Can you explain some of this 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.

I read RFC 6906 carefully and I don't see how you can say that "profile" 
as defined there 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.

Social Web Architect
http://bblfish.net/

Received on Friday, 17 January 2014 20:32:34 UTC