Re: Getting to closure on the remaining issues

On 01/23/2014 03:58 PM, Eric Prud'hommeaux wrote:
> * 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.

Somewhere in, at the fragment-id
#Container, I expect to find something saying that ldp:Container when
used with rel=profile denotes the Container interaction model as
defined in

Somewhere in{rdf,ttl}, I expect to find a
statement { #Container dcterms:description "@@same thing than in the
HTML@@" }.

Note: "clients SHOULD NOT indiscriminately access profile URIs." :-)


> 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

Received on Thursday, 23 January 2014 22:17:59 UTC