Linked Data Platform (LDP) Working Group Teleconference -- 15 Mar 2013

<Arnaud> trackbot, make minutes public

<trackbot> Sorry, Arnaud, I don't understand 'trackbot, make minutes public'. Please refer to <http://www.w3.org/2005/06/tracker/irc> for help.

<Arnaud> invite zakim

<Arnaud> zakim: make minutes public

<Arnaud> rssagent, help

<bblfish> hi

<Arnaud> trackbot, start meeting

<trackbot> Date: 15 March 2013

<bblfish> hi is the teleconf on?

<Arnaud> bblfish, not quite yet

<Arnaud> well, I started it but we need to call in

<Arnaud> we don't have the phone yet!

<Arnaud> coming up, hang in there

<Arnaud> scribe: cody

Scheduling next face to face

davidwood: last call period is minimum 3 weeks

<davidwood1> http://www.w3.org/2005/10/Process-20051014/tr.html#last-call

arnaud: Steve and I were looking at the calendar the other day. Doesn't seem that easy to find a week that's going to work that well.

… first week of June is Semtech in San Fran

… week of 3rd of June is out

… one possibility: aim for second week of June

<bblfish> I don't really hear anything. Arnaud is very distant, and there is background noise.

… discussing the WHERE

sandro: you're all welcome to come back here (M.I.T.)

arnaud: ashok agreed to host in New York, but others complained that it's expensive

migueal: We have to check for permission, but I think Madrid may be possible. We have to check for permission and get back to the group about that.

miguel = mesteban

<bblfish> ah the noise is better now

kevin: another thing to avoid is SWC which is like May 26

<bblfish> I can hear Arnaud and others discussing W3C AC meeting...

arnaud: if we want to give buffer with our last call, should we aim for a bit later in June?

sandro: the week of July 8th

<bblfish> The last call is already coming up?

<davidwood> yes

<bblfish> I thought this project was a 3 year project

<bblfish> and we were only in the first year

sandro: last week of June is European Sem Web conference

arnaud: I'm just wondering about May 20th

<mesteban> No, the ESWC is the last week of May.

arnaud: Except WWW conference is the week before

ashok: isn't that a bit early?

steves: I think it makes sense in this case, just to try to get to last call

arnaud: Either the week of 10th of June or week of 17th of June
... for now, let's go for the week of June 17th. We would do like 18, 19, 20 (if we want to do another 3 day)

F2F3 candidate locations, Madrid, London, or Boston (team favors that order), but arguing travel budgets

davidwood: let's do a straw poll

<bblfish> the noise has come back.

<Arnaud> strawpol: 1) madrid, 2) london, 3) boston

<ericP> 1 0 -1

<bblfish> +1 +1 -0.33333

<TallTed> -1, -1, +1

<Ashok> 0,0,1

<SteveS> +1, +1, +1

<sandro> -1 -1 +1

<cygri> +0.5 +1 0

<davidwood> -1 −1 +1

<JohnArwe> +1 +1 +1

<roger> +1, +1, +1

+0,+0,+1

<bblfish> ok

<SteveBattle> +1, +1, 0

<nmihindu> +1 0 -1

<mesteban> +1, +1, 0

<bblfish> I hear now.

<bblfish> that works

<bblfish> I'll check the charter

arnaud: it is not a 3 year project; we're chartered for 2 years

<davidwood> Charter: http://www.w3.org/2012/ldp/charter

<Arnaud> 0 +1 +1

<davidwood> 2012-06

<davidwood> F2F3

<davidwood> Face-to-face meeting, if needed

arnaud: OK, we'll leave it at that for now. We have proposed dates, locations, and a general straw poll

Open Issues

arnaud: technically we don't HAVE to take public comments into account at this point, but I think it wise to deal with them sooner, rather than later.

… need to figure out how we want to address the comments. davidwood, one of your colleagues, for example, submitted several

davidwood: somebody needs to get back to James formally, in the working group, and say that we acknowledge the comments

… I can do that. I'm sure Jame's perspective is similar to mine.

sandro: do we want to start tracking comments now? lc tracker?

… it's a comment tracker

<bblfish> Is someone scribing cygri's question because I did not hear what he said

cygri: would be good to report on how we tried to make sense of some of the terminology issues at dinner last night
... I don't know that we made consensus amongst ourselves, though

… What we talked about can be lumped under ISSUE 37 (the model)

… I objected to this notion that you could post to a container and then have a member of a container that is not an LDPR; I thought through and withdrawal that objection

<bblfish> Issue-52

<trackbot> ISSUE-52 -- base -- raised

<trackbot> http://www.w3.org/2012/ldp/track/issues/52

arnaud: lets talk about the issues we'd like to talk about today first, then we can sort out priority

… there is the one on batch versus patch

… we had binary

… and model

… missing any?

stevebattle: issue 50 (one of henry's)

<SteveBattle> issue-50

<trackbot> ISSUE-50 -- Intuitive Containers: better support for relative URIs -- open

<trackbot> http://www.w3.org/2012/ldp/track/issues/50

arnaud: So, we have to try to manage time here. Can we first try to see if the dinner helped us get anywhere related to pagination.

… Roger feels we rushed that

… ISSUE 33

<SteveS> ISSUE-33 ?

<trackbot> ISSUE-33 -- Pagination for non-container resources -- closed

<trackbot> http://www.w3.org/2012/ldp/track/issues/33

… Roger, is there anything you want to tell us about this issue to help us reconsider.

<SteveS> http://www.w3.org/2012/ldp/meeting/2013-03-14#resolution_1

… Have you slept on it?

roger: it seems that a lot of our issues, not just the pagination (update or patch, or for creation issues) ...

scribe is not yet understanding roger's point (hold on)

steves: post to add. We closed an issue a few days ago to say that we wouldn't do that

<SteveBattle> The example is about POSTing the literal string "Mary" to Peter; how would this generalize to other datatypes?

roger: I tried to identify useful concepts for pagination and updates. You essentially get something that looks like PATCH. A useful construct for both issues: patch and pagination

arnaud: how is that telling me that the decision we made yesterday is not a good one?

roger: yeah - on face value it looks kind of the same

tallted: updates could different if you've paginated or haven't paginated

arnaud: are we talking about robust pagination, which we have another issue for?

… still trying to figure out how they are linked together

ted: it will benefit us if richard could summarize the discussion last night

arnaud: agree - we need a debrief of last night

<cygri> http://www.w3.org/2012/ldp/wiki/User:Rcygania2/Richard%27s_LDP_101

… lets switch gears, forget ISSUE 33 for now, and discuss the informal break-out session from last night

LDP Model

cygr: my way of explaining how LDP works

… LDP has 2 parts to it:

documented in wiki "The two things that LDP does"

… Value sets : a set of triples with the same subject, same predicate, different object

… let's not get hung up on the term though

… you could call it a set of membership triples

… there is also the inverse

… same predicate, same object, but different subject

… LDP names value sets with an IRI

… and can be interacted with in various ways using HTTP.

<bblfish> What is the point of making this restriction?

<bblfish> I am worried that the notion of triple set is being introduced in order to restrict what should go in an LDPR...

… /foo/p1 s the IRI for a Value Set. If you do a GET on that URL, you'll get back those 3 triples

<roger> in my opinion it is being introduced to *partition* a LDPR

… but the URI of the Value Set is NOT the subject in the triples (unless maybe in some rare special cases)

<bblfish> to partition it into what?

<roger> into groupings according to predicate names

<bblfish> is this for Pagination partition membership?

tallted: imagine that each one of those 3 positions is filled with a full URI

cygri: the subject you have in the value sets is not the same as the URI of the value set

… the subject uri could be anything. It doesn't matter at all what the subject URI is (for this value et thing)

<bblfish> Yes, I still don't know why this concept is being introduced. Did I miss something?

… so in our example where the subject is foo, there could be other value sets that have foo as the subject

… container: value sets are really handy for building these REST style containers. The term container may lead to a narrow view of what you can do with them

… Value Set is my current conceptual replacement for what we've been calling Container

… the spec says you can PUT and PATCH to put any triples into this container; I don't see how that's helpful.

ashok: My worry is that if I want to create a container that has apples and oranges...

cygri: VS has single subject, single predicate. If you want a diff predicate, that's a diff value set

tallted: apples and oranges are objects, not predicates

johnarwe: membership triples in a container have same subject and predicate (been in the spec since beginning)

ashok: I'm hung up on the thing that the subject and predicate have to be the same in the collection

sandro: thats a normal RDF graph, this is a special kind of RDF graph that is more constrained

cygri: DELETE > two forms

<bblfish> cygri wants to turn RDF into a plain OO system.

<bblfish> You can see that he is thinking of URLs as objects with the methods and varialbes as the relations

<bblfish> But this removes a lot of flexibility from the system.

cygri: and the third thing is pagination

… you can follow a next pointer to get more triples in the value set

… Roger wants to add a single member to a value set by posting to a URI

<roger> … also wants to do dynamic introspection of what is possible with a value set

<nmihindu> +q

<SteveBattle> If I have value-set <foo/p3> I'm still unsure about what I can do on <foo>

cygri: in order to remove single member from a container in current spec, the only way is using PUT or PATCH

nandana: where does it differ from current spec, except for the naming changes?

cygri: I'm folding in some changes I'd like to see in paging, but that's a separate issue.

… what I'm trying to make clear is that

… there is a distinction between this subject resource and the Value Set

… by using the term Container, it doesn't make it mentally easy to keep those two things apart

<bblfish> ?

<JohnArwe> what is your ? henry

<bblfish> I don't understand where this is going.

… this is just describing the current spec in different words

arnaud: there are differences, that's not true

cygri: with the exception of paging, I don't think so

<SteveBattle> Do I get RDF if I do a GET on a value-set? (Yes)

<SteveBattle> If I want to delete a single triple from a value set, I still have to do a PUT or PATCH? (still unanswered)

<JohnArwe> henry: people had a sense that many of the disagreements were people talking past each other. at dinner several of those with widely different-sounding viewpoints came up with something we could all agree to.

<JohnArwe> ... to first order, the intent is that this is simply another way to speak about the same spec as we have today in terms more people can relate to.

… GET on a value set also gives some metadata. (see Metadata triples in value sets)

… GET on foo, you get some RDF and the met data triples about any value sets that use foo

<bblfish> there seems to be a suggestion that a LDPR should only contian one value set.

<JohnArwe> ... what complicated things slightly is (1) not everyone has all the ins/outs of the spec in their forebrains, so when cyrgi made certain existing aspects more explicit people are surprised (Kevin's pt) (2) cygri did introduced a change or two around pagination.

<JohnArwe> no, his intent is that one LDP*C* contains exactly one value set ... hence the stmts that "value set" can be thought of as just another name for today's "membership triples"

<bblfish> <> a foaf:PersonalProfileDocument;

<bblfish> foaf:primaryTopic <#me> .

<bblfish> <#me> a foaf:Person…

<bblfish> foaf:knows [ = <../jack#me>; foaf:name "Joe" ]…

<bblfish> How many value sets in there. How does this help?

… we have ability distinguish delete and recessive delete in the metadata

<JohnArwe> how many containers are in your sample henry?

sandro: essentially a domain-specific LDR

… LDPR

<bblfish> is this restricted to containers?

cygri: one of these containers exists purely for managing the values of a certain property.

<roger> i.e. an LDPC is not a domain resource

<bblfish> <> a ldp:Container;

<bblfish> :member [ = <card>; :title "Foaf Profile"; author [ = <jack>; foaf:name "Jack"; ] ] .

… container: managing the resource - not really a domain object. It exist in order to provide ability to add, remove, manipulate, page through members

<JohnArwe> as cygri is using the term, "value set" is essentially equivalent to "container" (his wiki page explicitly asserts that) ... he agreed informally as well as here that "v s" also equiv to "membership triples" b/c for him that set of triples are a major feature of containers, but also a feature that would be useful in other contexts

<SteveBattle> Can someone answer my PUT/PATCH question, "To change a value-set I still have to use PUT/PATCH?"

ashok: we agreed containers can have containers within them

… we've got to be able to put a value set in a value set

<JohnArwe> SB, I think it's on "have to" that differences might emerge. can you? yes.

<bblfish> Since Value set is a purely RDF graph centric thing, I don't see how it is related to containers. Containers is about resource creation. It happens to often be described by a pattern called a value set.

cygri: there's nothing that stops you from using the URI of another Value Set

stevebatlle: to modify a value set do I still use PUT and PATCH?

<JohnArwe> Henry, that sounds like violent agreement with cygri. As he pointed out last night, some people come at this from a REST/interaction viewpoint (so they care about create etc more), others from a more purely RDF standpoint (and for them the membership triples are more important)

<bblfish> Yes, but I don't see that you need restrictions to value sets.

<bblfish> graphs are good enough

tallted: this is the result of all of our conversation last night; doesn't lay the groundwork we began with. We discussed...

… current container: a factory, an enumerator, a modifier (including delete)

<bblfish> you want a new HTTP DELETE method?

<bblfish> RECURSIVE-DELETE ?

<bblfish> If you don't want a new HTTP delete method, then you want something like factory methods.

<JohnArwe> Ted was suggesting that, assuming we keep recursive delete which he was not especially a fan of, it should be an option on the delete request (however we do that) rather than a choice baked into a container's implementation all the time. if a container impln chose to only offer one kind of delete, I suspect he'd be fine with that as well.

<bblfish> ok.

<JohnArwe> ...while not part of cygri's page, informally ted mentioned that (as an example) http delete might always be NON recursive, and containers that offer recursive delete would advertise that by exposing a predicate we define whose object is a url that does the recursive delete

<SteveBattle> DELETE <URI>?recursively ?

<SteveBattle> (hoping zakim doesn't try to execute that!)

<Arnaud> http://www.w3.org/2012/ldp/wiki/User:Rcygania2/Richard%27s_LDP_101

<roger> arnaud: thanks cygri for the report

<JohnArwe> Scribe: Roger

arnaud: wants to know what we can do with value-sets going forward
... should the naming difference (container vs. value set) be carried forward ?

<davidwood> +1 to cygri for figuring out that we are overloading a core concept ("One issue with LDP as currently designed is that it doesn't really give you flexibility to use these three abilities independently.")

<Zakim> davidwood, you wanted to ask Richard what a "REST-style container" is

arnald: not everyone liked the filesystem analogy

cygri: a REST-style container is something you post to create something new

<JohnArwe> Note: not all "REST-style containers" support create, some are read/only

yes, but, there are not part of the 'model' as such, they are there to support interaction.

<bblfish> The sound is still very broken. Not sure if it is me, or something else

SteveS: is there are link from Steve to his friends value-set

<JohnArwe> broken ... static? volume low?

<bblfish> the sound goes up and down, and so I hear 3 words out of 5

<JohnArwe> is that any better? I'm not convinced they're actually speaking any louder

<bblfish> a very little bit better.

<bblfish> Let me try reconnecting with skype just in case

<JohnArwe> arnaud is moving the mic closer

<JohnArwe> roger: issue-51 was exactly that issue - how to find container from member

<bblfish> Issue-51?

<trackbot> ISSUE-51 -- Linking from a Resource to its Containers (aka 'backlinks') -- raised

<trackbot> http://www.w3.org/2012/ldp/track/issues/51

<JohnArwe> any better henry?

<bblfish> a bit better but still very choppy. I hear steve well.

<JohnArwe> steve B?

<bblfish> So I hear cygri not so good.

roger: the addition to issue 51 is how to discover an empty value-set - to bootstrap it's manipulation

<bblfish> Ashok is choppy too.

<bblfish> yes

ashok: if you access Steve you should get URI to each of its value-sets, right ?

where is the factory ?

arnaud: where is the factory ?

<TallTed> hopefuly plausible example:

<TallTed> valueSet: http://example.com/TedKnows

<TallTed> membershipSubject: http://id.myopenlink.net/dataspace/person/tthibodeau

<TallTed> membershipPredicate: foaf:knows

<TallTed> to add/change/delete

<TallTed> - MAY PUT/PATCH/POST to http://example.com/TedKnows

<TallTed> - MAY PATCH/POST to http://id.myopenlink.net/dataspace/person/tthibodeau

<TallTed> - MAY but SHOULD NOT PUT to http://id.myopenlink.net/dataspace/person/tthibodeau

sorry about the spelling

<SteveBattle> So, we can only use a value set where that has previously set up using a membership-predicate. We can't use value sets on any arbitrary property.

<davidwood> I have added the following issues as requested by the chair:

<davidwood> https://www.w3.org/2012/ldp/track/issues/53

<davidwood> https://www.w3.org/2012/ldp/track/issues/54

<davidwood> https://www.w3.org/2012/ldp/track/issues/55

<davidwood> https://www.w3.org/2012/ldp/track/issues/56

<davidwood> They were all based on comments made by James Leigh on the public comments mailing list.

@SteveBattle - unless you use some kind of lazy creation process and some kind of template

<bblfish> perhaps this microphone is not working as well as what we had yesterday.

<SteveBattle> I still don't get how Roger's back-links are supported by this.

Where there are changes to the text according to the discussions of this morning, this should be clearly visible.

they are not bloody back-links :)

<SteveBattle> How do I discover the 'container'/value-set from a member?

<JohnArwe> preference from several for editors to create high level list of places where the wiki text is adapted as it is incorporated as a resolution to issue-37

@SteveB: either as 1. explicit links for each VS, or 2. via some kind of templated link.

Awre: is this a potential resolution to issue 37 ?

<bblfish> can someone put the original microphone back. I heard the room better yesterday.

<SteveBattle> @roger: Insufficient data...

<cygri> ISSUE-15?

<trackbot> ISSUE-15 -- sharing binary resources and metadata -- open

<trackbot> http://www.w3.org/2012/ldp/track/issues/15

<bblfish> Issue-37?

<trackbot> ISSUE-37 -- What is the LDP data model and the LDP interaction model? -- open

<trackbot> http://www.w3.org/2012/ldp/track/issues/37

<bblfish> Issue-33?

<trackbot> ISSUE-33 -- Pagination for non-container resources -- closed

<trackbot> http://www.w3.org/2012/ldp/track/issues/33

<bblfish> ok

<sandro> (testing)

<SteveBattle> This is going way beyond pagination!

<JohnArwe> steve B, not grokking your !

Issue 17

<bblfish> Issue-17

<trackbot> ISSUE-17 -- changesets as a recommended PATCH format -- open

<trackbot> http://www.w3.org/2012/ldp/track/issues/17

<SteveBattle> @JohnArwe: The '!' represents my unease about discussing undocumented proposals.

<SteveS> http://www.w3.org/2012/ldp/meeting/2013-03-13#Issue__2d_17__3a__changesets_as_a_recommended_PATCH_format

<TallTed> we've run into a need to interrogate the server for its features/support at a number of points ... or at least, that ability would make (or have made) several things easier

<sandro> sandro: the server would need to advertise any patch-extensions it understands; the client MUST NOT assume the extensions are present unless its seen the server advertising it.

<SteveS> See Accept-Patch header http://tools.ietf.org/html/rfc5789#section-3.1

<sandro> (yes, that's one way to advertise it.)

<sandro> (if we clone trig to other media types.)

<sandro> issue-17?

<trackbot> ISSUE-17 -- changesets as a recommended PATCH format -- open

<trackbot> http://www.w3.org/2012/ldp/track/issues/17

arnaud: perhaps issue 17 is close-able with an action to develop something more concrete based on AndyS email.

<Arnaud> Proposed: Use Andy's proposal http://lists.w3.org/Archives/Public/public-ldp-wg/2013Mar/0058.html as the basis for solving issue-17

<sandro> +1

<SteveS> +1

<mesteban> +1

<Ashok> =1

<SteveBattle> +1

<rgarcia> +1

<TallTed> +1

<cygri> +1

<nmihindu> +1

<JohnArwe> +1

<Arnaud> Resolved: Use Andy's proposal http://lists.w3.org/Archives/Public/public-ldp-wg/2013Mar/0058.html as the basis for solving issue-17

<sandro> (test)

<Arnaud> lunch break for 30mn

<TallTed> scribenick: TallTed

cody: valueSets are another way of describing LDPCs, as I hear it

…LDPC is a concept, which should be concisely defineable.

…if you can't do that, it seems it's really more than one concept.

…excellently reworded definition will be typed in!

<cody> A concise (an in my opinion, more proper) definition of an LDPC:

Arnaud: best way to make progress, is to make concrete proposals, like that

sandro: starting point is sometimes 10 minutes finding out whether others share my pain, vs spending a week to come up with a proposal nobody else cares about

<cody> "An LDPR representing a collection of same-subject, same-predicate triples, which is uniquely identified by a URI that responds to client requests for creation, modification, and enumeration of its members."

issue-15?

<trackbot> ISSUE-15 -- sharing binary resources and metadata -- open

<trackbot> http://www.w3.org/2012/ldp/track/issues/15

ISSUE-15

<cody> In the Trminology section of the spec, I think it may be more helpful to have such concise definitions rather than a sort of "cop out" pointer to the lengthy section (calling that the definition).

<SteveBattle> However, this definition doesn't mention the additional metadata that an LDPC may have, eg. for defining membership predicates.

Arnaud: idea that when you post a binary to a container, 2 resources are created, 1 being metadata. question is which of these is the "member" and which is "external"

ericP: paraphrasing richard, expectation had been that when a resource was got from a container, it would return RDF

<SteveBattle> Is the POSTed binary added to the container, and if _not_ how do you get the correct deltion behaviour?

ericP: issue is the "extra magic" of how to delete extraneous material (and what that is) when the member is deleted

<SteveBattle> My own preferred magic sauce is to have the metadata live inside the container, so it's naturally deleted along with the container.

cygri: the argument that made me object yesterday was the consistency...

… that the client knows that when it iterates through a container, it gets RDF back from all its members

… now we know that we want these to be very generic things, and their handling as well

… members are just links, at the end of the day, and just because you use an LDPC to manage these objects, doesn't mandate that they must all be LDPRs

ericP: value of membershipPredicate pointing at newly created resource is higher than pre-knowing the type of all those resources

cygri: an LDPC might refuse to accept a POSTed image -- if *that* LDPC only contained Turtle files...

… we're basically telling the client they cannot rely on LDPC members being LDPRs

SteveS: common pattern is to make the POSTed resource's URI the member value. changing that will mean changing much more.

davidwood: has it been decided how a client will know it's talking to an LDP server, and if so, what kind of LDP server?

Arnaud: discovery is part of ISSUE-32. we have a proposal to flesh that out.

sandro: question is are you talking to an LDPC, or an LDPR (not to an LDP server).

<sandro> issue-32?

<trackbot> ISSUE-32 -- How can clients discover that a resource is an LDPR or LDPC, and what features are supported? -- open

<trackbot> http://www.w3.org/2012/ldp/track/issues/32

davidwood: I've determined I'm not talking to either LDPR or LDPC, but an image. should I not know I'm talking to an LDP server?

sandro: should be able to follow Link: rel header, and determine the answer...

<roger> it could be that if a resource has links to its value-sets, then it is a LDPR, otherwise it is something else .. (?)

Arnaud: pulling back to the agenda... discussion of how cygri concluded that he was OK with yesterday's breakout proposal

ericP: I feel like we should come up with an answer about DELETE, but can see backward compatibility with existing application patterns has value

<JohnArwe> david, in your new issue please be as clear as possible what it this buys you that introspection of the resource [server's] capabilities ala 21/32 discussions will not. or at least which aspects of the server's behavior you'd certainly want a client to discover via your issue.

<davidwood> ok

<Arnaud> proposed: POST whatever you want to the container, and it gets given a URI I and returned as normal, but ALSO a metadata resources P is created. When you GET I, you get back a LINK header leading youto P. When you GET P, there's some triple with the same link information, leading you to I.

<SteveBattle> I agree with John & Eric, the DELETE behaviour is under-specified.

[back-and-forth about whether I and P are or can be the same URI]

cygri: MUST, MAY, SHOULD?

JohnArwe: [composing spec vocally]

cygri: all this is optional anyway... so the server may do this additional?

<JohnArwe> Assuming the existing qualifications that POST is optional, and supporting "binary" media types is optional:

<SteveBattle> The metadata resource does not only comprise server-managed properties, a client may add additional metadata.

<JohnArwe> ... The expected response to a post for create is a 201, with location header whose URI identifies the resource whose representation matches the POST input, and the response MAY include a Link header rel="meta" href= another URI identifying the resource whose state is the server-managed properties.

<SteveBattle> It's may not be a simple LDPR URI, but possibly a hash URI within an LDPR

<JohnArwe> ...those two URIs MAY be distinct.

[vocal tinkering...]

<JohnArwe> PROPOSAL: Assuming the existing qualifications that POST is optional, and supporting "binary" media types is optional: The expected response to a post for create is a 201, with location header whose URI I identifies the resource whose representation matches the POST input, and the response MAY include a Link header rel="meta" href= another URI P identifying the resource whose state is the server-managed properties.

<JohnArwe> When the object of a membership triple (I) is DELETEd, the server MUST automatically deletes any related resource P that it created previously.

<JohnArwe> ...The URIs I and P MAY be distinct, but this is not required.

<roger> +1

<bblfish> back, travelled from Paris to Fontainebleau during break

<davidwood> I suggest changing "MAY include a Link" to "SHOULD include a Link".

<bblfish> can't hear anything

<SteveBattle> Even for an RDF resource?

<bblfish> thanks

<bblfish> +!

<davidwood> …in order to ensure we don't conflict with any later resolution related to discoverability.

<mesteban> JohnArwe, should we discourage then sending DELETE to P?

davidwood: my only change would be MAY to SHOULD for Link header

<JohnArwe> @miguel, fine by me

SteveBattle: seems redundant if POST was turtle

cygri: proposal now reads as if this happens even for turtle. not sure if that's the intention.

<bblfish> logger?

<Arnaud> strawpoll: 1) what john wrote (with MAY), 2) same with SHOULD instead of MAY

<bblfish> zakim pointer?

cygri: the way this is described, "here's a useful pattern that servers may want to use in a certain case"

<bblfish> got it thansk :-)

cygri: there will be implementations that don't want to deal with binary resources, and SHOULD forces extra work there

davidwood: implementations aren't required to support binaries, but if they *do*, they SHOULD do it this way

<bblfish> +1 for davidwood

Ashok: echoes davidwood.

<SteveBattle> "When the object of a membership triple (I) is DELETEd" - In the case of an inverse membership property, the binary is the subject.

<davidwood> -π +1

Arnaud: strawpoll: 1) what john wrote (with MAY), 2) same with SHOULD instead of MAY

<JohnArwe> steve b: correct

<cygri> 1 -0.2

<Ashok> 0,1

0, +1

<mesteban> 0,+1

<JohnArwe> ...needs to factor inverses in, but we also need something to start w/ before changing it I hope.

<SteveS> 0, 0

<cody> 0,0

<krp> 0,+0.8

<nmihindu> 0, +1

cygri: don't see why we're getting into specifying patterns for metadata of binary resources...

<bblfish> Mhh, I don't understand this proposal

<JohnArwe> 1,1

<SteveBattle> 1,0 (subject to rewording of "object of membership triple")

<cody> my 0,0, is pass (out of ignorance)

<rgarcia> +1, 0

<Ashok> Henry, MAY ad metadata or SHOULD add metadata

<mesteban> Then my vote should be +1, +1.

<bblfish> ah ok I got it

<SteveS> +1, +1 should have been my vote -- I want this text for binary resources and associated meta resource, neutral on whether it should be MAY or SHOULD

<bblfish> +1,0 (

<bblfish> oops

<bblfish> I mean 0,+1

<bblfish> I can still hear arnaud

<Arnaud> Proposed: Close issue-15 with: Assuming the existing qualifications that POST is optional, and supporting "binary" media types is optional: The expected response to a post for create is a 201, with location header whose URI I identifies the resource whose representation matches the POST input, and the response SHOULD include a Link header rel="meta" href= another URI P identifying the resource whose state is the server-managed properties.

<Arnaud> ... When the object of a membership triple (I) is DELETEd, the server MUST automatically deletes any resource P that it created previously.

<SteveBattle> 0

"...The URIs I and P MAY be distinct, but this is not required."

<bblfish> +1

drafting and redrafting...

<JohnArwe> PROPOSAL: close issue-15 with: Assuming the existing qualifications that POST is optional,

<JohnArwe> and supporting "binary" media types is optional: The expected response to a post for create

<JohnArwe> that creates a non-LDPR is a 201,

<JohnArwe> with location header whose URI I identifies the resource whose representation matches the POST input,

<JohnArwe> and the response SHOULD include a Link header rel="meta" href= another URI P identifying the resource

<JohnArwe> whose state is the server-managed properties.

<JohnArwe> When the object of a membership triple (I) is DELETEd, the server MUST automatically deletes any

<JohnArwe> related resource P that it created previously.

<SteveS> +1

<cygri> -0.2

<mesteban> Shouldn't we include Ted's clarification?

<krp> +1

<Ashok> +1

<rgarcia> -1

<bblfish> +1

<nmihindu> +1

<davidwood> +1

<SteveBattle> 1 (subject to rewording of "object of membership triple" in the case of inverse membership properties)

<JohnArwe> PROPOSAL: Close issue-15 by saying: Assuming the existing qualifications that POST is optional,

<JohnArwe> and supporting "binary" media types is optional: The expected response to a post for create

<JohnArwe> that creates a non-LDPR is a 201,

<JohnArwe> with location header whose URI I identifies the resource whose representation matches the POST input,

<JohnArwe> and the response SHOULD include a Link header rel="meta" href= another URI P identifying the resource

<JohnArwe> whose state is the server-managed properties. The URIs I and P MAY be distinct, but this is not required.

<JohnArwe> When the object of a membership triple (I) is DELETEd, the server MUST automatically deletes any

<JohnArwe> related resource P that it created previously.

seventeenth time's the charm!

<rgarcia> +1

<ericP> +1

<SteveS> +1

<nmihindu> +1

<cygri> -0.21

<roger> +1

<mesteban> +1

<krp> +1

<SteveBattle> 1 (subject to rewording of "object of membership triple" in the case of inverse membership properties)

<davidwood> +1

<bblfish> +1

<JohnArwe> +1

mesteban: what happens when we send a DELETE for P?

<JohnArwe> Miguel raised a question earlier... one way to address that might be: LDPC servers SHOULD NOT allow clients to delete

<JohnArwe> server-managed resources like P.

<SteveBattle> P is deleted?

<Arnaud> Resolved: close issue-15

PROPOSAL: LDPC servers SHOULD NOT allow clients to delete server-managed resources like P.

<bblfish> ?

SteveBattle: I don't agree that these properties are only server-managed

<JohnArwe> LDPC servers SHOULD NOT allow clients to delete resources like P.

<SteveBattle> 0

<bblfish> ah you mean one should not be able to delete the metadata about a binary if the binary exists.

<davidwood> I disagree with TallTed.

<davidwood> TallTed is saying something like, "A server MAY decide to create and separately manage metadata about its resources. Clients MAY NOT be allowed to delete server-created resources."

<cygri> For the record: I prefer LDP to be concerned only with managing RDF representations, with the possibility to extend it for other kinds of data. This decision adds a half-baked protocol for managing non-RDF resources, and I don't think that should be in LDP.

mesteban: the server decided to create that additional resource, so it shouldn't allow deletion

(2 minute break...)

<bblfish> I'll go make good coffée too here...

(reconvene)

Arnaud: do we continue pursuing this? or leave it at that?

davidwood: small group conversation... server can create its own server-managed metadata that clients can't touch.

…server can also create LDPRs or LDPCs on its own that are exposed to client interaction.

…if server decides to create metadata that only it controls, it can do that

Ashok: 2 kinds of metadata. which one does the link header point to?

…could have multiple Link headers!

<davidwood> Good question! Could a server expose metadata to a client that no client is allowed to act upon?

<SteveBattle> …nothing to stop user-managed and server-managed triples being in the same LDPR

davidwood: I like software systems that eat their own dogfood. where high level functionality is built on the low level functionality.

… way to implement an LDP server is for that server to make use of all this RDF stuff it has floating around, REST interactions, etc.

… if that server already has some sort of permissions structure, it's easy to use that on its own created metadata

<bblfish> Agree: the ACL system can be used to give permissions on resources and metadata

<SteveBattle> Sounds like we need a separate issue about server-managed properties and ACL's?

P = container, 2 contained resources, 1 for server, 1 for client. :-)

<JohnArwe> @SB: "need" implies you are requesting a change, so if so... yes

Arnaud: what do we do next? administrivia awaits (review RAISED issues, etc.)

issue-51?

<trackbot> ISSUE-51 -- Linking from a Resource to its Containers (aka 'backlinks') -- raised

<trackbot> http://www.w3.org/2012/ldp/track/issues/51

<bblfish> ah ok. The title is very misleading

[rewording to correct intent]

<cygri> Linking from a membershipSubject to its containers

JohnArwe: will expose the cognitive double-entendres

<davidwood> ISSUE-51 may be a tautology: If a resource is referenced, we don't need to separately reference them...

<bblfish> The problem is that one needs now something saying that this is NOT backlinks

<davidwood> +1 to bblfish

"ISSUE-51: Linking from a Resource to the Containers which it contains (not the containers the resource is in)"

which makes the Resource a Container

SteveS: example on Net Worth, 1.9, may be relevant...

how do you get from an LDPR to the valueSets (a/k/a LDPCs) of which it is Subject?

<ericP> <containerPage1> { <http://example.org/netWorth/nw1> o:asset <a1>,<a2>. <a1> a o:Stock . <a2> a o:Cash>

<ericP> }

<ericP> <a1> { <a1> a o:Stock ; o:value 100.00 ; dcterms:title "IBM" }

<ericP> <a2> { <a2> a o:Cash ; o:value 50.00 ; }

<bblfish> perhaps put that in the issue then

<SteveBattle> I only just grokked that a value-set is what was formerly known as an LDPC.

<davidwood> bblfish, the diagram roger drew looks something like this: A container (A) links to a resource (B), resource (B) in turn links to containers (C) and (D). ISSUE-51 is about the links from B to C and B to D.

<JohnArwe> henry you can also look at ex 2 from the LDP spec; in that context, the question is how a client "finds" /nw1 (and any other containers) from a resource like <>

<bblfish> ok.

<bblfish> Just take a picture of the picture and post the above explanation in the issue report

<JohnArwe> ...and do that WITHOUT implying somehow that <> MUST be a container (which was the problem with the "child link" alternative, that it suggested this unwanted effect)

<SteveBattle> I need concrete written examples before I can process this properly.

<bblfish> but if B links to C and D what is the issue?

roger: wants a MUST that you get :steve'sFriends ldp:membershipSubject :Steve when you dereference :Steve...

<davidwood> bblfish, That's what we are trying to articulate :)

<davidwood> Frankly, I'm confused, or at least I think I am.

<bblfish> does it matter, any relation will do no?

<bblfish> ( well not any relation, but there could be many relations relating a resource to a container - an infinity to be precise )

roger: is accustomed to getting :Steve in ?subject position for all relevant statements, not used to looking at ?object as well

<bblfish> if you want to say something is a container. then you can have { B link C . C a ldp:Container .}

<JohnArwe> I could try it as a variation on LDP spec ex 2: instead of <> being a container itself, imagine that it *has* two containers, one for assets and one for liabilities. If a client is given the URL for <>, how does the client find out about the assets and liabilities containers?

<Arnaud> resolved: open issue-51

<Arnaud> reopen issue-51

<trackbot> Re-opened ISSUE-51 Linking from a Resource to its Containers (not the containers the resource is in).

<bblfish> should the title not be "Linking from a Resource to containers"?

Arnaud: moving on... issue52

issue-52?

<trackbot> ISSUE-52 -- base -- raised

<trackbot> http://www.w3.org/2012/ldp/track/issues/52

<davidwood> Possible duplicate with ISSUE-54

<davidwood> ISSUE-54?

<trackbot> ISSUE-54 -- Which URIs should replace null relative URIs provided in LDPR representations? -- raised

<trackbot> http://www.w3.org/2012/ldp/track/issues/54

bblfish: logged based on email to the list. looked at spec as-of-today, and saw confusion about the meaning of <>

<bblfish> http://www.w3.org/TR/2013/WD-ldp-20130307/#http-post-1

<roger> @TallTed, just for the record, looking at the ?object doesn't freak me out entirely, I just want to be follow the signposts simply, rather then pre-assuming knowledge of the destination to find forward signposts.

<bblfish> 5.4.8 In RDF representations, LDPC servers must interpret the

<bblfish> null relative URI for the subject of triples in the LDPR

<bblfish> representation in the request entity body as referring to the

<bblfish> entity in the request body. Commonly, that entity is the model

<bblfish> for the “to be created” LDPR, so triples whose subject is the

<bblfish> null relative URI will usually result in triples in the created

<bblfish> resource whose subject is the created resource.

bblfish: this suggests that the parser behavior must be changed

<Zakim> davidwood, you wanted to suggest combining ISSUE-52 and ISSUE-54 by pulling ISSUE-54 content into ISSUE-52 and closing ISSUE-54 as duplicate. ISSUE-52 should be opened.

PROPOSED: merge content of issue-52 and issue-54, closing 52, and OPENing 54 for future discussion/resolution

<cygri> +1

<SteveBattle> +1

<bblfish> ok

<JohnArwe> +54 ... or +52

Arnaud: +1

<SteveS> +1

<nmihindu> +1

<mesteban> +1

<cody> +1

<rgarcia> +1

<bblfish> +1 to closing 52 and add 52 as a solution to 54

<davidwood> +1

<roger> +1

RESOLUTION: merge content of issue-52 and issue-54, closing 52, and OPENing 54 for future discussion/resolution

<bblfish> Issue-53

<trackbot> ISSUE-53 -- Which Content Types should be returned to bots? -- raised

<trackbot> http://www.w3.org/2012/ldp/track/issues/53

Arnaud: issue 53. oh yes. seems clearly justified. let's open it.
... opened by acclamation.

<Arnaud> resolved: open issue-53

<Arnaud> reopen issue-53

<trackbot> Re-opened ISSUE-53 Which Content Types should be returned to bots?.

issue;55?

issue-55?

<trackbot> ISSUE-55 -- Hypermedia as the Engine of Application State (HATEOAS) Compliance -- raised

<trackbot> http://www.w3.org/2012/ldp/track/issues/55

Arnaud: issue 55 also seems to have a valid point, may resonate with Roger

[discussion - some past comments comes to mind here, but no resolution is remembered]

Arnaud: without objection.... opening issue-55

<Arnaud> resolved: open issue-55

<Arnaud> reopen issue-55

<trackbot> Re-opened ISSUE-55 Hypermedia as the Engine of Application State (HATEOAS) Compliance.

<cygri> strong +1 to opening 55

<bblfish> Issue-56

<trackbot> ISSUE-56 -- How can clients discover LDPR PUT URLs? -- raised

<trackbot> http://www.w3.org/2012/ldp/track/issues/56

TallTed: open it

<mesteban> +1 to davidwood

<Arnaud> resolved: open issue-56

<Arnaud> reopen issue-56

<trackbot> Re-opened ISSUE-56 How can clients discover LDPR PUT URLs?.

sandro: a good answer may be "don't do that. only PUT on something you can GET"

<cygri> sandro: Only ever do a PUT when you can do a GET

<bblfish> Issue-57

<trackbot> ISSUE-57 -- How can a client determine that it is in communication with an LDP service? -- raised

<trackbot> http://www.w3.org/2012/ldp/track/issues/57

Arnaud: issue:57 -- identifying an LDP service

<cygri> Duplicate of ISSUE-32?

davidwood: several other issues touch on this, but I think it's cleaner to resolve them all generally, than each as a special case

<bblfish> do an HTTP GET on the resource ?

<davidwood> cygri, please note the text in the issue: "NB: The answer to ISSUE-32 may or may not provide an answer to this issue as well. If so, this issue may be closed concurrently."

<bblfish> or have the other resource describe it as a ldp:Resource .

<SteveBattle> Are there precedents for services/servers/resources advertising themselves via an HTTP header?

<davidwood> SteveBattle, sure, Web servers tell you what they are.

arnaud: "service" to be changed to "server" in the issue
... barring objection... open issue 57

<Arnaud> resolved: open issue-57

<Arnaud> reopen issue-57

<trackbot> Re-opened ISSUE-57 How can a client determine that it is in communication with an LDP server?.

issue-58?

<trackbot> ISSUE-58 -- Property for asserting that complete description of members is included in LDPC representation -- raised

<trackbot> http://www.w3.org/2012/ldp/track/issues/58

<bblfish> how long is the break for?

Arnaud: [summarizes issue description]

+1 open

<bblfish> ah ok, so this is a bit like an atom:feed containing atom:entry

<bblfish> so that you get something of a description in the LDPC ?

SteveBattle: is this continuing with LDPCs being valueSets?

<cody> Could use clarification on the meaning of " So that a client doesn't have to dereference each member in order to be sure that it has complete data."

<JohnArwe> Henry: let's say that your LDPC server has 4 triples about a member. If GETting the LDPC returns 2 of those member's triples, Richard's flag would be off. If the LDPC returns all 4, the flag would be on.

<bblfish> ah ok.

<JohnArwe> The flag is essentially an optimization to allow clients to know there is no value in GETing the member; they can, but they will obtain no new triples.

<SteveBattle> So I've just grokked that value-sets can also contain item-level properties.

SteveS: could use the pagination indicators, include next=NULL or similar

<bblfish> It makes sense to open it, but I think it is very odd.

Arnaud: look to example 3 in the spec... cygri wants to know whether there are more triples to be retrieved about <a1> than are present in this example, without GETting <a1>

+1 open

<roger> +1

<davidwood> +1

<SteveS> I was saying have <a1, ldp:nextPage, rdf:nil>

<SteveS> +1

<Arnaud> resolved: open issue-58

Arnaud: objections to opening issue-58? none? open.

<JohnArwe> +1

<bblfish> the problem I see is that you have an ldp:thisIsAllThereIS , then that is a relation between a document and something.

<cygri> SteveBattle, the model is that a container is a set of triples where they all have the same s and p. But when you GET a container, it may give you some other triples besides those

<Arnaud> reopen issue-58

<trackbot> Re-opened ISSUE-58 Property for asserting that complete description of members is included in LDPC representation.

<bblfish> My guess is that you will find merging information about these things a bit odd.

<bblfish> ah yes, so how long is the break now?

<JohnArwe> 15 mins

<JohnArwe> sorry 15 total only 10 left now

<bblfish> opening some wine here, and preparing dinner

<cody> Photos of the F2F2 working group posted to: http://www.w3.org/2012/ldp/wiki/Special:ListFiles (Panorama.png.zip, IMG0981.JPG.zip, IMG_0980.JPG.zip, IMG_0979.JPG.zip)

<davidwood> Nice! Think of us while we are flying :)

<SteveBattle> Cygri, even if those triples are defined in separate LDPRs? This behaviour isn't defined for LDPCs (I guess it isn't outlawed).

<cygri> SteveBattle, I think the NetWorth example in the spec does this (inlining parts of the member descriptions)

<SteveS> Scribe: SteveS

Arnaud: Steve is scribe, thank you

<davidwood> ISSUE-49?

<trackbot> ISSUE-49 -- Canonical URL - how to communicate its value to clients -- open

<trackbot> http://www.w3.org/2012/ldp/track/issues/49

Issue- 49

Ashok: this is not special for LDP and consider removing 4.1.4

cygri: agree is with Ashok it is not just and LDP problem, consider moving to deployment guide to warn/help implementers

sandro: Google supports rel = canonical

<Zakim> davidwood, you wanted to ask whether a server will always have a canonical URL for a resource

Ashok: in order to support it the server would need to know what this is

<SteveBattle> cygri, you're correct re: NetWorth example - thanks.

Arnaud: Ashok, so you are ok with deployment guid?

Ashok: yes

<sandro> http://tools.ietf.org/html/rfc6596 rel=canonical

davidwood: ok with it being non-normatively defined

sandro: this is new, not even a year old

davidwood: who supports this?

sandro: servers support it, I think
... though Google says they prefer it, they prefer 303 redirect

davidwood: asking if there is a mechanism, 3xx or link conancial

Ashok: said support removing it

JohnArwe: Yves pointed out a security issue with different URLs

…who recommended not to go there

<davidwood> PROPOSAL: Close ISSUE-49 saying that LDP will not further restrict HTTP in this area.

Proposal: Close Issue-49 removing 4.1.4 and consider giving some guidance in the deployment guide

<TallTed> +1

<Ashok> +1

<SteveBattle> +1

<sandro> +1

<nmihindu> +1

<mesteban> +1

<cygri> +1

<rgarcia> +1

<davidwood> +1

<krp> +1

<roger> +1

davidwood: prefer to have a more descriptive proposal

<davidwood> PROPOSAL: Close ISSUE-49 saying that LDP will not further restrict HTTP in this area. Remove section 4.1.4 from the spec and consider giving some guidance in the deployment guide.

<SteveBattle> +1

<davidwood> +1

RESOLUTION: Close ISSUE-49 saying that LDP will not further restrict HTTP in this area. Remove section 4.1.4 from the spec and consider giving some guidance in the deployment guide.

<mesteban> +1

ISSUE-35

ISSUE-35?

<trackbot> ISSUE-35 -- POSTing to a container MUST yield a fresh URI -- open

<trackbot> http://www.w3.org/2012/ldp/track/issues/35

Arnaud: give some background and origins around delete and previous language about server reusing URLS

cygri: related to previous delete issue but be better to say POSTing to create a resource, it creates a new URL

…later if server creates another resource, it should never reuse a URL

TallTed: not sure a client would expect this behavior, due to a number of factors such as restarts, restores, etc

ericP: it is like w3c doesn't have to honor its URLs

cygri: if domain changes owner, the new domain will violate if it reuses URLs

TallTed: hard to what the old server, app was hosting and never use

<SteveBattle> What about weakining this to SHOULD rather than MUST?

cygri: not saying related to delete, just focused on new URLs for POST

bblfish: should this be a should? must seems to strong

ericP: if relaxed to should, client can't depend on the behavior

cygri: there are an extreme to have some unexpected failures

Arnaud: wonders if this is a quality of service thing, like coolURIs don't change

cygri: if you want to implement a reliable service, a should sounds weak

rgarcia: it is impossible to test a server violates it

sandro: it is hard but if you get a dupe you know it failed

davidwood: hard for a server to keep track of it

sandro: there are a number of ways to keep track of it

TallTed: we are forbidding reuse of URLs on POST but not of PUT

<davidwood> This is already a best practice ("Cool URIs don't change", PURLs, "Cool URIs for the Semantic Web"…)

cygri: POST we say a URLs is minted, PUT is replacing the state

<davidwood> LDP shouldn't separately define this, I think.

TallTed: there is no difference if the content is replaced behind it, using PUT

davidwood: thinks this is an HTTP issue and not a LDP thing

<Arnaud> strawpoll: add 1) MUST not reuse 2) SHOULD not reuse 3) nothing

<bblfish> +1,+1,0

<TallTed> -1, +1, 0

<rgarcia> -1, +1, 0

<SteveBattle> 0, +1, 0

sandro: it is valid HTTP POST cases that using URIs

<nmihindu> -0, +1, 0

<sandro> +1 -0.99 -0.99

<cygri> +1 -1 -1

<mesteban> 0, +1, 0

<roger> 0, +1, +1

<davidwood> -1 0 +1

+1, +1, 0

<Ashok> 0,1,1

JohnArwe: there is some discussion of this in the delete section

<ericP> +1, -1, 01

<JohnArwe> +1,0,-0.5

<ericP> +1, -1, -1

<krp> +1,+1,0

cygri: as a server implementer I have a good reason to not do this, if should it allow servers to reuse and they'd comply

<davidwood> RFC 2119:

<davidwood> SHOULD This word, or the adjective "RECOMMENDED", mean that there

<davidwood> may exist valid reasons in particular circumstances to ignore a

<davidwood> particular item, but the full implications must be understood and

<davidwood> carefully weighed before choosing a different course.

<davidwood> https://www.ietf.org/rfc/rfc2119

<davidwood> MAY This word, or the adjective "OPTIONAL", mean that an item is

<davidwood> truly optional.

TallTed: fact that content has same abs urls, that server needs to keep track it and generate things unique

<SteveBattle> I'm convinved by Ted's argument. When you completely reset a server it should have no memory of it's previous state.

cygri: it is possible to keep track of every resource you create

<bblfish> everybody is speaking together

sandro: gets complicated if support Slug or client indicated URLs

<SteveBattle> Yes - this should happen during the lifetime of a server instance. But not beyond that lifetime.

<davidwood> bblfish, we need a Babel Fish :)

Arnaud: there is a burden, it is reasonable for servers to do this

<bblfish> :-)

ericP: LDP wouldn't be very useful if URIs were reused, it does come down to URIs

on the RDF validator, if you want a picture you get with a URI, which only lasts for about 10 minutes

<bblfish> good idea +1 for sandro

sandro: in the spirit of consensus we could follow the SHOULD statement

explaining the cases which it is allowed to violate

<sandro> sandro: ... with a very strongly worded explanation of WHY

Arnaud: wants to hear from those who think it is so expensive to do

<nmihindu> +q

<TallTed> 6. Guidance in the use of these Imperatives

<TallTed> Imperatives of the type defined in this memo must be used with care

<TallTed> and sparingly. In particular, they MUST only be used where it is

<TallTed> actually required for interoperation or to limit behavior which has

<TallTed> potential for causing harm (e.g., limiting retransmisssions) For

<TallTed> example, they must not be used to try to impose a particular method

<TallTed> on implementors where the method is not required for

<TallTed> interoperability.

cygri: understanding that certain acts of nature or things hard to predict will affect many of the conformance statements, and size of data, running out of storage, etc

…other factors like domain moves

<davidwood> TallTed: This is not an appropriate use for MUST in accordance with RFC 2119 because it is not required for interoperabilty.

nmihindu: a use case, i work for upm, I no longer work for them so they delete my URI and then I rejoin and they may recreate a URI for me

cygri: it is possible to use something like PUT to backfill a resource at a previous URI

<davidwood> The LDP WG ironically redefines Ouroboros

<sandro> sandro: we're just talking about the case where you WANT a dispenser of fresh URLs.

<bblfish> what does HTTP say about POST?

<sandro> nothing, bblfish

<sandro> this has nothing to do with HTTP or POST. It's about whether a network service can be defined to hand out fresh URLs.

<TallTed> refresh strawpoll: add 1) MUST not reuse 2) SHOULD not reuse 3) nothing

davidwood: proposing that we let people think about it and come back to it

<TallTed> -1, +1, 0

<SteveBattle> 0, +1, 0

<cygri> +1 -1 -1

bblfish: wanted to see if anyone changes

<sandro> +1 -.99 -.99

<bblfish> +1,+1,-1

<ericP> +1, -1, -1

+1, +1, 0

<nmihindu> 0, +1, 0

<sandro> +1 -.5 -.5

<mesteban> 0, +1, -1

<krp> 0,+1,-0.5

<JohnArwe> no chg

<Ashok> 0,1,1

<rgarcia> -1, +1, -1

<cygri> ISSUE-44?

<trackbot> ISSUE-44 -- 4.1.9. is obscure or too restrictive -- open

<trackbot> http://www.w3.org/2012/ldp/track/issues/44

ISSUE-44

JohnArwe: explains motivation that it is trying to avoid the more complex case

cygri: thinks that we don't need to say this within the spec or deployment guide

<davidwood> PROPOSAL: Close ISSUE-44 by removing section 4.1.9 from the spec.

<rgarcia> +1

<SteveBattle> +1

<davidwood> +1

<bblfish> +1

<TallTed> +1

<krp> +1

<nmihindu> +1

<Ashok> +1

<mesteban> +1

<JohnArwe> +1

RESOLUTION: Close ISSUE-44 by removing section 4.1.9 from the spec.

Arnaud: thanks davidwood you did find an easy one

<bblfish> Issue-13?

<trackbot> ISSUE-13 -- Include clarifications about BPC representations that include member triples -- open

<trackbot> http://www.w3.org/2012/ldp/track/issues/13

ISSUE-13

<bblfish> I have had too much wine

<bblfish> s/$/ Can't follow... (hic)/

PROPOSAL: CLOSE ISSUE-13 as editorial - answering- BPCs can have members that are not BPRs?

<davidwood> PROPOSAL: Close ISSUE-13 by saying that the spec editor will align sections 4.1.2 and 5.2.6. Also, BPCs can have members that are non-BPRs.

<rgarcia> +1

<davidwood> +1

<nmihindu> +1

<krp> +1

JohnArwe: spec is silent on this so left open

cygri: if a client updates/puts triples in the container representation, we should be clear on this.

…perhaps goes in client deployment guide, highlighting how a client might deal with this

Arnaud: take the first resolution on the first part of it, then 2nd part as updating of resources

<TallTed> PROPOSAL: Address first part of ISSUE-13 by saying that the spec editor will align sections 4.1.2 and 5.2.6. Also, BPCs can have members that are non-BPRs.

cygri: should probably say that a client should not make this can of request (update resource data through a container) and what it can't

seems to be good at saying what a server can do

<JohnArwe> must step out for mtg now

<TallTed> +1 davidwood

<Arnaud> Resolved: Address first part of ISSUE-13 by saying that the spec editor will align sections 4.1.2 and 5.2.6. Also, BPCs can have members that are non-BPRs.

Resolved: Address first part of ISSUE-13 by saying that the spec editor will align sections 4.1.2 and 5.2.6. Also, BPCs can have members that are non-BPRs.

<davidwood> PROPOSAL: Close the remainder of ISSUE-13 by saying that the membership of BPCs may not be directly modified by clients; membership is modified solely via actions on resources.

<TallTed> davidwood - "mimic 5.5.1 from PUT under 5.4 POST and/or 5.8 PATCH"

<TallTed> ?

SteveBattle: wonders if it can update data about a container from a resource or about the member resource within a container

<davidwood> TallTed, yes, I think so

cygri: explains the container representation in example 2

<rgarcia> PROPOSAL: Close the remainder of ISSUE-13 by saying that members of a container cannot be updated through PUT/PATCH to a container

bblfish: might be nice to leave patch open a container, where you can patch remove a bunch of members of a container

<SteveBattle> -1

<JohnArwe> henry: the question here is whether or not a put/patch on the container is allowed to modify contents of members. since a container MAY return those member triples on a GET against the container.

<bblfish> perhaps the solution is to move this remainder to another issue

<bblfish> a more precise one

<JohnArwe> +1 to henry

<cygri> PROPOSAL: Close the remainder of ISSUE-13 by saying that servers may refuse to update inlined members through PUT/PATCH to a container

<davidwood> +1

SteveBattle: think that it is hard to know the boundaries of resources isn't clear, whether to update the container and member resource

cygri: the spec says that a container is only putting member information for convenience on a GET response

<sandro> +1

<rgarcia> +1

<bblfish> ah with the may it's sounds ok

<JohnArwe> +1

<bblfish> +1

<krp> +1

<nmihindu> +1

<TallTed> +1

<sandro> eric: +1

<mesteban> -1

Arnaud: could be cases where the member resources only exist in container rep, such as <#a1>

cygri: that is why it is a may, to allow for this

Arnaud: declaring no consensus and scribe is expiringsf
... on Monday we have informal call

will hope to have minutes out (but you want be able to see it if he doesn't)

Arnaud: meeting adjourned

<bblfish> ok, thanks all folks.

<bblfish> enjoy your evening.

<mesteban> bye.

<JohnArwe> night henry

<TallTed> for a bit of RDF fun, http://chatlogs.planetrdf.com/swig/2013-03-15

<TallTed> "Intead of a ( S P O ) triple, I propose to use a tuple: ( S P O R C A E DNT AD GS IW )"

- DRAFT -

Linked Data Platform (LDP) Working Group Teleconference

15 Mar 2013

Attendees

Contents

Scheduling next face to face

Open Issues

LDP Model

Issue 17

ISSUE-15

Issue- 49

ISSUE-35

ISSUE-44

ISSUE-13

Summary of Action Items

Scribe.perl diagnostic output