Re: Action-126: Proposal to materialize ldp:contains

On 01/20/2014 08:39 AM, John Arwe wrote:
>> With your proposal, LDP will depend normatively on this, so we'll have
>> to hope that these dependencies will become stable soon enough for LDP
>> to go to REC.
>
> Speaking as a certified lead-lined tinfoil hat wearer, the easy solution
> is to make it At Risk and make the call at CR.  If we dump it at CR, then
> clients get all triples in 1.0, this probably lands on the ".next" list,
> and anyone who cares can implement the draft as an extension.  Fin.

Sounds like a plan.

>>> from the client) would normally return them.  LDP could try Must'ing
> that,
>>> at the risk of eliciting more comments along the lines of Mark Baker's
>>> (and perhaps Erik W, and IETF generally)
>> [snip: Alexandre's insertion]
>>> that we're intruding on base
>>> specs by over-specifying how servers form representations most
> appropriate
>>> to the client according to WebArch.
>>
>> Can you say why you think this is "over-specifying"?
>
> I'm not saying that I think it is, I was anticipating others' likely
> responses based on past experience discussing their comments (and their
> reasoning that led to same) with them.  My perception is that they are
> strong advocates for a point of view that gives the server huge amounts of
> freedom in determining what the "right" response is for a given situation.
>   It's that position that leads to conclusions like "200 + a subset of the
> state with links to more of it is fine" (how to respond to a GET when the
> server decides to page the result).  While not everyone agreed with that
> specific conclusion, it's a point of view that I see coming through in
> many IETF specs.  "over-specifying" was my way of summarizing that
> position, is all.

I understand. But we're defining a protocol so I personally won't say
that this is "over-specifying".

>> 1. Does this replace 5.9.1 altogether? Do we still expose non-member
>> and non-containment resources?
>
> If we choose to adopt this mechanism to ALSO cover the
> non-member-properties case, I think exposing them is server choice.  Any
> minimalists would probably then conclude "remove all mention of them
> [non-member-properties , non-containment resources] from the spec - it's
> complex enough already".  I would have sympathy for that position,
> personally.

So would I.

I honestly don't think this is crucial to LDP 1.0 given the Prefer
approach and I would support removing it for the sake of
simplicity. And if this is really important, that feature could easily
be re-added in LDP Next anyway.

I think it'd be easy for Arnaud to make the group vote on that
PROPOSAL. I won't be surprised if we have everybody ok with "remove
all mention of them [non-member-properties , non-containment
resources] from the spec". And if somebody is strongly opposed, then
let's just keep it.

>> 2. The spec does not prevent inlining (nor encourage it) and it _can_
>> be useful for a hashless-ContainerResource to inline the containment
>> triples from the related containers. I would then expect those
>> "normally" inlined containment triples not to be returned if the
>> client prefers to omit them. If you agree, do you think we should have
>> a remark that mentions inlining in this proposal?
>
> I don't think the spec even _contains_ the _word_ inlining at this point,
> given that we took a decision some time ago to remove it as an At Risk
> feature based on LC1 feedback (IIRC *I* removed it, and normally I'd
> search before declaring 'done').  I have not looked back at it after that,
> I have enough trouble staying current with the LDP email traffic.  Given
> recent progress on alternatives like TriG that are immune to the
> provenance problems that Henry alerted us to, those would be the first
> thing I'd look at personally.

Ok that's fine.

TriG is nice but not necessary in my opinion. If I GET
<http://example.com/foo>, I know that as an Linked Data client, I
should consider as authoritative only the statements about
<http://example.com/foo> itself or the derived hash-URIs as
<http://example.com/foo#bar> or <#bar>. I would consider anything else
as being inlined.

Maybe that could go into Good Practices.

Alexandre.

>
>
> Best Regards, John
>
> Voice US 845-435-9470  BluePages
> Tivoli OSLC Lead - Show me the Scenario
>

Received on Monday, 20 January 2014 19:35:58 UTC