Linked Data Platform (LDP) Working Group Teleconference -- 24 Feb 2014

<trackbot> Date: 24 February 2014

<deiu> Zakim: MIT531 is me

I suppose I could scripte

Overview

Arnaud: We are going to change the order of the agenda a little bit
... because of feedback

minutes of last meeting

<ericP> scribenick: bblfish

<deiu> Minutes seemed ok

Overview of Agenda

http://www.w3.org/2012/ldp/wiki/Meetings:Telecon2014.02.24

Arnaud: We are going to change the order of the agenda a little bit

because of feedback

laste week's minutes

Approved: last week's minutes http://www.w3.org/2013/meeting/ldp/2014-02-17

Actions

Steve reports on completing unnamed action of splitting the spec

Low Hanging Fruits

209

who is speaking again?

<SteveS> ericP

<deiu> ericP

ericP: is saying a lot here...

<Arnaud> http://www.w3.org/2014/02/2xx/draft-prudhommeaux-http-status-209

Arnaud: the tension is a bit less because it is only the paging spec that depends on 209

me: a lot of other things in the semweb would depend on it too :-)

ericP: if one can test this on a bunch of systems that would be helpful
... it would be interesting to test this in existing linked data applications

the people who make this mistake would be those who mistake information resources and non-information resources

scribe: this would be useful for feedback on IETF
... github would find this useful for github, as they don't differentiate one group of issues from others. This could be argued to be pathological
... and due to there not being a 209

<Ashok> Eric, how long do you expect the IETF process to take?

<deiu> bblfish: isn't schema.org the one that returns a different url for identity? they can be an ally

<deiu> ... my feeling is that 3XX might be a bit better (it has a notion of redirect), while for 2XX space it could be confusing for people

<deiu> ericP: the fact is that 2XX is returning content, while 3XX is about the redirect and not the final product of the redirect

<Zakim> sandro, you wanted to ask about allies

bblfish: why not in the 3xx space?

ericP: because there seems to be a lot of agreement that 3xx is only about the headers and redirects

Mhh, perhaps I can go to IETF

Sandro: this is server only redirect, and sandro thinks about suggesting a client preference for a redirect
... the client could suggest the redirect

<sandro> Client says: Prefer: follow-link rel=first

Sandro is suggesting http://lists.w3.org/Archives/Public/public-ldp-wg/2014Feb/0100.html

ericP: John Arwe had made a similar suggestion with respect to a Prefer header, though John had a 303 in his proposal

SteveS: there is an editorial note taked for 308

ericP: that was because he compied the 308 RFC

Ashok: what are the expectations on how long that is going to take

ericP: at IETF London next week there should be a response with the apps ...
... it is helpful as the w3c acting director is supporting this and is the liaison with IETF

<sandro> ( I see Content-Location is the location of THIS PARTICULAR representation )

ericP: one remaining issue: was not sure if sandro is better 209 over 200

sandro: prefers 209 over 200
... the 209 spec would use a prefer header as an example - they would not be tied together

the question was how complex is it to get a new prefer header

<sandro> prefer registry = http://www.iana.org/assignments/message-headers/message-headers.xhtml

the answer seems to be vague between it's just a registration to w3c specs may have some automatic speed way to registration

<sandro> or not: http://tools.ietf.org/html/draft-snell-http-prefer-18#page-13

Sandro's https://www.w3.org/2012/ldp/wiki/Collection_Types

Sandro: finding the Collections and the members to be confusing as they are smushed together
... if synchronisation is a problem, or access control can be problematic, ... various extensibility problems

TallTed: is not that happy about the use cases, that may be ephemeral, and that end up being used as a justification for a lot of features
... there seems to be a need for a container which when deleted removes all contained resources and a container that when removed must remove all contained resources
... and it should be easy to have both
... Sandro's proposal seems to be like a rehash of previous issues that were resolved some time ago. So there was at a previous F2F the idea of a factory method that could be used to say do a rm -rf on a directory
... one should remove the temptation of simplification for the sake of simplification because there are all these use cases

<roger> I don't think that the factory method is doing deleting - it is doing creation.

Arnaud: was worried because of the reliance on PATCH everywhere

sandro: the current spec has the same problem with PATCH

<deiu> bblfish: I haven't had time to look at the spec carefully, but the notion of containership was that there are things that have containment.

<deiu> ... my feeling is that one can go down to the basic building blocks

<deiu> ... one should first do a POST (create a doc), then PATCH to modify contents

<SteveS> you can do that with BasicContainers if you want that

<deiu> ... the idea is that there are consequences to doing certain actions

<deiu> ... the high lever thinking is not so clear, and perhaps if we can understand what we're doing with these two different things, then people will understand WHY we're doing it

<Zakim> sandro, you wanted to ask how people think of the two-headed monster -- when they are looking in different directions

<ericP> sandro, i'm having a hard time writing something into 209 to use Prefer before Prefer: follow-link is defined.

<ericP> e.g. 'A client MAY indicate that it expects a 209 status code with a header like "Prefer: follow-link rel=first".'

<roger> sandro: why would I want a container that has membership triples which are different to the containment triples ?

<roger> is that correct ?

<ericP> in Annotea, some clients wanted hosting and others didn't.

<ericP> it was really a question of whether they owned some other web space into which they wrote their annotations.

<ericP> (in response to Sandro's question of why one container would accept both POST and PATCH)

qoops forgot to keep scribing

Ashok: found sandro's write up easy to understand

and that it's a better write up

SteveS: an explanation for the need of the double headed beast. Why not have as bblfish said a simple POST to create an ldp:contains and then PATCH the returned URL somewhere else.
... but with the bug report use case it is useful to have the action of POSTing have as a consequence the addition of the membership triple to another resource

<SteveS> I have a few edits I'd like to make to help with understanding, so would request another week before making decision on going to LC (or at least be clear on what actions are needed to make LC2)

Arnaud: Sandro proposes a new notion of Selection that is underspecified ( would take a lot of time to get it right ). What is a problem would be if we found that we had cornered ourselves. But if people don't like the InderectContainer and DirectContainer. The problem might be the naming of the IndirectContainer to ldp:Container decided last week

since with the ldp:PlainContainer things are the way sandro likes it

scribe: from a logical point of view this makes sense. But the ldp:BasicContainer is also an indirectContainer.

<sandro> +1 rename ldp:Container back to ldp:IndirectContainer

<sandro> +1 removing the class heirarchy

<sandro> (to reduce tying ourselves to the current model)

<SteveS> I like the hierarchy we have but understand how some of the model complexities might make into the simplest thing

<sandro> ApplicationDomainContainer === IndirectContainer ?

<Zakim> sandro, you wanted to push forward, maybe with IC and DC "at risk".

<TallTed> ldp:Container has 2 disjoint subclasses -- ldp:BasicContainer, ldp:AdvancedContainer

<TallTed> AdvancedContainer has 2 subclasses -- and 1 AdvancedContainer could be both of these -- ldp:IndirectContainer, ldp:DirectContainer

<SteveS> right, think soap/wsdl would have same issues

<sandro> Arnaud, I'd love to propose to go to LC, but I'd also like to address my PREFER point.

yes

<SteveS> I can stay

<sandro> Henry, the client IS NOT RESPONSIBLE for what people infer, incliduing what the server infers.

<Zakim> sandro, you wanted to bring up my PREFER request as well

I was just explaining what the importance of binding is

what is a client bound to when it POSTs a graph to a LDPC. It seems it is bound to the content of the graph and the ldp:contains relation . But for more advanced containers it seems the client is bound to the extra triples appearing. This is not made clear in the spec. Here binding is not the same as causal consequence. POSTing G could have as causal consequence that a bomb goes off, but the client is not bound to that consequence: he is certainly

h not responsible for it.

<sandro> |Prefer: return=representation;

<sandro> include="http://www.w3.org/ns/ldp#PreferEmptyContainer"|

I am not sure I have a grasp of these proposals

<SteveS> Agree with sandro, it would be good to have a URI for container metadata

<SteveS> ...we seem to have lost that (had it with ?non-member-properties) and added Prefer

<sandro> { ?x ldp:contains ?y } => { member-constant membership-predicate ?y }

<sandro> that's how tyou make an IndirectContainer

<sandro> PROPOSED: Revert ldp:Container back to ldp:IndirectContainer, and remove class hierarchy relation among the Container types

<sandro> keeping ldp:Contains as the abstract class if folks really want it.

<sandro> oh no.... we lost Ashok, and he can't call back because we're over time.

<ericP> setting X=1 is idempotent but it has side effects

<sandro> sandro: The client is NEVER responsible for what ends up in the Container. The client is ONLY responsble for the triples in its posting.

btw. I'm happy that we just have this discussion on this issue of what the consequences of POSTing are. This is really useful to understand

<sandro> PROPOSED: Revert ldp:Container back to ldp:IndirectContainer, and remove class hierarchy relation among the Container types. With ldp:Container as the abstract base class of the three subclasses.

<sandro> or BasicContain is the base class.

Arnaud: is ldp:BasicContainer rdfs:subClassOf ldp:IndirectContainer .

<sandro> strawpoll: basic is base class, or basic is not base class

so ldp:contains has as domain rdf:IndirectContainer ?

<SteveS> +0 for reverting to LDPC parent class and subclasses

<Arnaud> PROPOSED: make BasicContainer -> Container, have Direct and Indirect subclasses

<sandro> -0

<SteveS> +/- 0

-0.8

<TallTed> -0

<deiu> 0

I am pretty sure that's wrong

<SteveS> ok, I change to +0.3

<sandro> PROPOSED: Revert ldp:Container back to ldp:IndirectContainer, and remove class hierarchy relation among the Container types. Use ldp:Container as the abstract base class of the three subclasses.

<Arnaud> PROPOSED: make Container abstract, have Basic, Direct, and Indirect subclasses

<sandro> +1

<SteveS> back to what we had on 2/16 basically

<TallTed> +0.5

<SteveS> +0.01

<codyburleson> Oops. Dropped on accident and conference is restricted to re-enter. :-(

<sandro> PROPOSED: include server MAY include rel=describedby, and if so it gets the empty-container triples.

<SteveS> +1

<sandro> +1

<deiu> +0 (I need to think about it some more)

<sandro> SteveS: we removed this, because we had prefer, but we lost the IRI

<SteveS> RFC5988 describes describedBy

<TallTed> +0.8

<sandro> s/describeby/describedBy/

+0 don't have anything against it. Not sure what the use case is

<SteveS> I need to drop

<sandro> MembershipContainer and IndirectMembershipContainer

<TallTed> DirectMembershipContainer and IndirectMembershipContainer

<TallTed> subclasses of MembershipContainer :-)

thanks. I'll read those proposals more carefully for next time.

I liked TallTed's argument about two-directional arguments :-)

I wonder if I have to close this

trackbot, end meeting

- DRAFT -

Linked Data Platform (LDP) Working Group Teleconference

24 Feb 2014

Attendees

Contents