Re: Discovery/Affordances (Issue-32/Issue-57)

On 6/10/13 2:43 PM, Wilde, Erik wrote:
> hello arnaud.
>
> On 2013-06-10 11:22 , "Arnaud Le Hors" <lehors@us.ibm.com> wrote:
>> Henry Story <henry.story@bblfish.net> wrote on 06/10/2013 09:09:43 AM:
>>> ...
>>> So as argued above you can use the Link header and also use the
>>> ldp:Container there in the same
>>> way as you do with the body. What is the profile adding?  What
>>> vocabulary would need to be used to
>>> describe the profile?  Do we need this now or can we add it later?
>>> Unless those questions are answered
>>> this seems like a lot of work to do when we can just use
>>> ldp:Container to mean: you can POST to this
>>> container.
>> I have to admit not to know what it takes to create a profile but I
>> wonder why you think this is a lot of work. Maybe Erik can help us there?
>> I see this is as a simple marker that doesn't require much anything else
>> than be defined in the spec as a way the server can advertise it is
>> supporting LDP.
> that's exactly its intent. specifically, profile URIs are defined as being
> *identifiers only*, meaning that there is no required/defined vocabulary
> for defining/describing them. a community minting a profile or a set of
> profiles might want to settle on such a vocabulary (using their metamodel
> of choice, which in the LDP case probably would be RDF), but that's
> optional and not required by the spec.
>
> http://tools.ietf.org/html/rfc6906#section-1: "The profile link relation
> type is independent of the context in which it is used and does not
> constrain, in any way, the target of the linked URI. In fact, for the
> purpose of this specification, the target URI does not necessarily have to
> identify a dereferencable resource (or even use a dereferencable URI
> scheme). Clients can treat the occurrence of a specific URI in the same
> way as an XML namespace URI and invoke specific behavior based on the
> assumption that a specific profile target URI signals that a resource
> representation follows a specific profile.  Note that, at the same time,
> it is possible for profile target URIs to use dereferencable URIs and to
> use a representation (which is outside the scope of this specification)
> that represents the information about the profile in a human- or
> machine-readable way."
>
> cheers,
>
> dret.
>
>
>
Here's what is say, bearing in mind that LDP means "Linked Data 
Platform" based on RDF:

"  This specification registers a 'profile' link relation type according
    to the rules of RFC 5988 [RFC5988].  Links with this relation type
    can be used in representations that support typed links as well as in
    HTTP Link headers.  The profile link relation type is independent of
    the context in which it is used and does not constrain, in any way,
    the target of the linked URI.  In fact, for the purpose of this
    specification registers a 'profile' link relation type according
    to the rules of RFC 5988 [RFC5988].  Links with this relation type
    can be used in representations that support typed links as well as in
    HTTP Link headers.  The profile link relation type is independent of
    the context in which it is used and does not constrain, in any way,
    the target of the linked URI.  In fact, for the purpose of this
    As one example, consider the case of podcasts, where a specific kind
    of feed uses additional fields for media-related metadata.  Using a
    'profile' link, it would be easily possible for clients to understand
    that a specific feed is supposed to be a podcast feed, and that it
    may contain entries using podcast-specific fields.  This may allow a
    client to behave differently when handling such a feed (such as
    rendering a podcast-specific UI), even when the current set of
    entries in the feed may not contain any podcast entries. (Section
    5.3 gives more details for this example.)
"

Conclusion: use something that is neither Linked Data (no de-reference) 
nor RDF (no machine comprehensible entity relationship semantics) 
oriented as a mechanism for those that want to write code around a 
"profile" marker.

Personally, if that's what it takes (and I've expressed this position in 
the past) to move forward, then fine. Maybe as folks actually implement 
and cross test implementations these matters will get much clearer.

Anyway, those of use arguing our positions also have implementation 
experience on our side. We've implemented WebDAV, Atom, SPARQL Graph 
Protocol, and now LDP. As implementation grow, I am confident clarity 
about some early-implementer concerns will become clearer.

-- 

Regards,

Kingsley Idehen	
Founder & CEO
OpenLink Software
Company Web: http://www.openlinksw.com
Personal Weblog: http://www.openlinksw.com/blog/~kidehen
Twitter/Identi.ca handle: @kidehen
Google+ Profile: https://plus.google.com/112399767740508618350/about
LinkedIn Profile: http://www.linkedin.com/in/kidehen