proposal on ldp:profile ( Issue-48 ) -- was: Discovery/Affordances (Issue-32/Issue-57)

On 10 Jun 2013, at 20:43, "Wilde, Erik" <Erik.Wilde@emc.com> 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.

I think the problems in our discussions comes from this way of phrasing things, 
as it confuses two seperate topics:

  a) how do you know a resource is an LDPC/LDPR ? ("that it is supporting LDP")
  b) how do you constrain what types of resources can be member of an LDPC .

The profile is doing the second thing (b) . To take Erik Wilde's informational
RFC6906

[[
   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.  (
]]

( Btw. there is a link to Apple's podcast feed in section 5.3 but that feed 
contains no profile link relation I could find )

If we want now to map this to LDP and RDF, we can say that the profile relation 
is constraining the types of the ldp:contains members ( ISSUE-79 ). So
we could have an ldp:profile relation such that the following rule
holds:

[Rule 1]
{ ?ldpc a ldp:Container;
      ldp:profile ?ldpRType;
      ldp:contains ?member } => { 
   ?member a ?pType 
}

so then 

ldp:profile a rdf:Property;
   rdfs:comment """
      an ldp:profile relation relates a particular LDPC to a subclass 
      of ld:Resource. In this way it functions a bit rdf:type, except
      that it applies to all the ldp:contains ( contents ) of the LDPC
   """@en;
   rdfs:domain ldp:Container;
   rdfs:range [ rdfs:subClassOf ldp:Resource ] .

With the above definition we get both
 (a) a simple way of knowing something is an LDPR/LDPC which fits 
    with our current spec ( the resource says it is an LDPR or an LDPC,
    or a subclass of those )
 (b) a way of constraining membership in an open ended manner in a
    way that happens to be compatible with (a)

So to take Erik's example of podcasts it would be easy for someone to
define the following

♫:Podcast rdfs:subClassOf ldp:Resource;
     rdfs:comment """
       the class of all Podcast LDPRs, ....
     """@en .

Then if a client discovers an LDPC <podc> that says of
itself that

<> a ldp:Container;
   ldp:profile ♫:Podcast .

Then the client would know that POSTing to <podc>
would always need to add the relation to the newly 
created resource <newPod>
(as per ISSUE-73 adapted to ISSUE-79)
eg:

  { <> ldp:contains <newPod> . }
 
and that because of the [Rule 1] above it can
conclude that

  <newPod> a ♫:Podcast .

So he would also know that the POST has to be of a podcast
type thinggy.  I think this means that for clients that
came across an LDPC which had some ldp:profile relations
to a type that the client did not know, then it should not
be surprised that the POST is refused.

This could be checked with the semantic web community, but 
I think it gives Erik what he wants, and it remains simple
and easy to understand, while also having a formal RDF model.

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

Social Web Architect
http://bblfish.net/

Received on Tuesday, 11 June 2013 06:57:56 UTC