W3C

- DRAFT -

Linked Data Platform (LDP) Working Group Teleconference

05 Nov 2012

Attendees

Present
MacTed, JohnArwe, Arnaud, ghard, jkopecky, dret, SteveS, AndyS, Yves, Sandro, MHausenblas, cygri, ericP, +1.937.279.aabb, Kalpa, bblfish, deiu
Regrets
Chair
SV_MEETING_CHAIR
Scribe
bblfish

Contents


<MacTed> trackbot, start meeting

<trackbot> Date: 05 November 2012

<Yves> JohnArwe, you mean having duplicate members?

<JohnArwe> Yves, no. I remember language somewhere saying that members could be added by the container without POST requests. E.g. if someone creates a file in a filesystem, the container implementation could detect it and add it as a member "internally" (i.e. w/o POST)

<AndyS> JohnArwe - I'd expect resources to be created then added to one or more containers in additional to in the container first. c.f. file system links, mv

<Yves> JohnArwe, ok. Adding things outside of network interaction is not something the spec should talk about, it may happen, but not linked to our spec

<Yves> one question might be "is it OK to create a member using PUT"

<JohnArwe> Yves, Ok thx. If I see the language I referred to before in the future, I'll raise an issue to remove it.

<SteveS> JohnArwe, we resolved ISSUE-25 stating that it would follow composition semantics, POST to container would create and add. We have a resolution to investigate supporting weak aggregation. ISSUE-25 edits have NOT been made

<JohnArwe> SteveS that's fine, but fundamentally I am/was asking about the semantics of "composition semantics" as defined by this WG. Is that question out of order?

<SteveS> JohnArwe, no, just giving a summary of where things stand

<sandro> http://www.w3.org/wiki/LDP_Implementations

<AndyS> Yves - is that because the name is "under" a container? (seems reasonable)

<cygri> sandro, AndyS, we *did* talk about it, but didn't resolve it.

<Yves> a container is a member of its container, no? so if it's a member, it's resolved per previous resolution

<dret> if the server creates container, it maybe should attach associated behavior.

<dret> it's probably not quite clear what to do: accept the "container data" and become a manager of that piece of data, or accept the "container semantics" and become a manager of a new container.

<Zakim> ericP, you wanted to talk about Bart's use case

<dret> sounds very useful, but only works if the server manages both containers, right?

<Zakim> AndyS, you wanted to ask about mv

<dret> maybe that's a good issue to discuss? REST-wise, binding resource relationships to URI structures would be unfortunate.

hi

yes

<betehess> +1 re: "binding resource relationships to URI structures would be unfortunate"

<dret> in AtomPub, clients suggest URIs, but servers pick them (upon creation), and they pretty much always (i've never seen another implementation) pick URIs under they authority. if we remove this constraint, interactions become rather different, because a link from the container to an contained item can move across authority boundaries.

<dret> i don't hear anything right now. planes?

<sandro> http://www.w3.org/wiki/LDP_Implementations

<mhausenblas> +1 to sandro

<JohnArwe> dret, authority is an organizational scope - is this not like URIs in general, where "if authority1 != authority2, client MUST assume they are different" but the server may have additional knowledge (like it's told via config that it "owns" URI assignment under both authorities)

<mhausenblas> reminds me to add http://paygoo.info/ and continue implementing it ;)

<sandro> :-)

yes was very helpful

great chairing

<dret> thanks, arnaud!

learnt a lot :-)

<ghard> Thanks!

<ghard> Bye

thanks

<jkopecky> thanks indeed

<deiu> small comment: can't add new entries on the implementations wiki page (only editing existing entries works)

<Arnaud> oh, sandro?

<Arnaud> deiu, don't you have an edit button at the top of the page?

<AndyS> Opps - I didn't press a button ... one moment

<deiu> Arnaud, no

<Arnaud> are you logged in?

<deiu> yes

<Arnaud> weird

<deiu> I only have an edit button next to each entry

<Arnaud> I have page discussion edit history etc.

<Arnaud> when I click edit I can edit the whole page

<deiu> Right, got it

<deiu> I was expecting to see that button near the contents list

bye

bye AndyS

<MacTed> http://www.w3.org/2012/ldp/meeting/2012-11-01

<MacTed> http://www.w3.org/2012/ldp/meeting/2012-11-02

<MacTed> http://www.w3.org/wiki/EditingData

http://www.w3.org/wiki/LDP_Implementations

http://doodle.com/9g9zibrmcvs3t9xa?

<MacTed> trackbot, end meeting

Summary of Action Items

[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.137 (CVS log)
$Date: 2012/11/05 16:25:31 $

Scribe.perl diagnostic output

[Delete this section before finalizing the minutes.]
This is scribe.perl Revision: 1.137  of Date: 2012/09/20 20:19:01  
Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/

Guessing input format: RRSAgent_Text_Format (score 1.00)

No ScribeNick specified.  Guessing ScribeNick: bblfish
Inferring Scribes: bblfish

WARNING: No "Topic:" lines found.

Default Present: MacTed, JohnArwe, Arnaud, ghard, jkopecky, dret, SteveS, AndyS, Yves, Sandro, MHausenblas, cygri, ericP, +1.937.279.aabb, Kalpa, bblfish, deiu
Present: MacTed JohnArwe Arnaud ghard jkopecky dret SteveS AndyS Yves Sandro MHausenblas cygri ericP +1.937.279.aabb Kalpa bblfish deiu

WARNING: No meeting chair found!
You should specify the meeting chair like this:
<dbooth> Chair: dbooth

Found Date: 05 Nov 2012
Guessing minutes URL: http://www.w3.org/2012/11/05-ldp-minutes.html
People with action items: 

WARNING: Input appears to use implicit continuation lines.
You may need the "-implicitContinuations" option.


WARNING: No "Topic: ..." lines found!  
Resulting HTML may have an empty (invalid) <ol>...</ol>.

Explanation: "Topic: ..." lines are used to indicate the start of 
new discussion topics or agenda items, such as:
<dbooth> Topic: Review of Amy's report


WARNING: IRC log location not specified!  (You can ignore this 
warning if you do not want the generated minutes to contain 
a link to the original IRC log.)


[End of scribe.perl diagnostic output]