Re: Getting to closure on the remaining issues

* Alexandre Bertails <> [2014-01-23 15:07-0500]
> Hi Eric,
> On 01/22/2014 09:09 PM, Eric Prud'hommeaux wrote:
> >* Arnaud Le Hors <> [2014-01-22 15:36-0800]
> >>Hi all,
> >>
> >>As you all know we've been slipping off track with regard to our schedule
> >>to deliver a Recommendation by the time our WG expires (1 June 2014). We
> >>cannot afford any further slippage. See the timeline I laid out:
> >>
> >>
> >>What this means, practically, is that we no longer have time to
> >>investigate and debate issues at length. We HAVE to close every remaining
> >>issue one way or another. If we can't agree on a resolution then we will
> >>postpone the issue. Yes, that means we may have unresolved issues. Nothing
> >>is perfect.
> >>
> >>The good news is that while we still have several pending issues, I
> >>believe we can close them all quickly (yes, really). We've got proposals
> >>for all of them and it's "merely" a matter of getting these accepted.
> >>
> >>Of course this is only to get us to LC2 and there is no way to tell what
> >>will come out of it but that's beyond our control.
> >>
> >>In the agenda for next Monday I put forward a set of proposals on how to
> >>revolve every remaining issue:
> >>
> >
> >Persuant to the agendum for ISSUE-92 - Interaction Model, tests for
> >creation of sub-container
> >   <>
> >and archival of container
> >   <>
> >use these header specifications respectively:
> >   Link: val=<LDP1ContainerInteraction>; rel=profile
> >   Link: val=<LDP1ResourceInteraction>; rel=profile
> >
> >Here, <LDP1ResourceInteraction> stands for whatever the WG chooses to
> >identify the HTTP interactions defined in §5
> >   <>
> >
> >and <LDP1ContainerInteraction> stands for whatever the WG chooses to
> >identify the HTTP interactions defined in §6
> >   <>
> >
> >These are concrete test cases which I hope will appeal to the folks
> >waiting in the wings for something implementable.
> To be clear, the proposal does not change the value for the
> rel=profile relation, except maybe for the typos in the spec
> as it's supposed to be
> :-) Same for ldp:Resource.
> I know you wanted to avoid the confusion between the class and the
> object. 

make that "interaction model"

>         That would actually align with the rationale of changing
> rel=type to rel=interaction. That being said, I think it's fine to
> keep ldp:Resource/ldp:Container as values because a class is just a
> URI as others that can can be used as object. We would just make sure
> that by dereferencinng them, we found find the information about using
> them in the context of rel=profile and everything would be just fine.

Defenders of using "ldp:Container" to identify the interaction model
have stated that doesn't bind us to using only one interaction model
to manipulate properties of RDF nodes of type ldp:Container. I'm very
curious how they will support that in the text that comes back when
you dereference ldp:Container. I propose something like

"ldp:Container identifies a graph structure with the following schema.
It does not identify any particular interaction model for manipulating
nodes with that structure."

> Alexandre.
> >
> >
> >>Be prepared to cast a vote on every one of them or accept not to have a
> >>say. I will not further delay resolution on these.
> >>
> >>I know this has been trying for everyone and it's been hard for some to
> >>stay on top of everything. The thing is I don't think the world would fall
> >>apart no matter how any of these decisions would go. So, let's just decide
> >>one way or another and move on.
> >>
> >>Thanks.
> >>--
> >>Arnaud  Le Hors - Software Standards Architect - IBM Software Group
> >


office: +1.617.599.3509
mobile: +

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.

Received on Thursday, 23 January 2014 20:59:02 UTC