- From: Henry Story <henry.story@bblfish.net>
- Date: Tue, 11 Jun 2013 08:57:22 +0200
- To: "Wilde, Erik" <Erik.Wilde@emc.com>
- Cc: Arnaud Le Hors <lehors@us.ibm.com>, "public-ldp-wg@w3.org" <public-ldp-wg@w3.org>
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