See also: IRC log
<trackbot> Date: 17 April 2014
<Ashok> scribenick: Ashok
Arnaud: Access control and Patch
format are on the agenda with testing in the afternoon.
... I think we need to talk about the spec again. Esp. about
JSON-LD.
... also talk about paging a bit more.
<codyburleson> *has also the noise
Arnaud: We can delay
testing
... start with Access Control Note now. Then spec and
paging
... and patch
... I don't see a quick solution to PATCH.
Arnaud: This was a compromise we
came to when we wrote the charter
... did not want to put on charter because it's a hard issue.
So we decided on a separate note.
<codyburleson> Annoying noise just stopped
Arnaud: on yesterday's wish list
discussion Access Control was high priority
... we need agreement on usescases
<deiu> Ashok: we started on this and we have 2 requirements
<deiu> ... one: you need some form of authentication
<deiu> ... however, we don't want to specify the authentication protocol
<deiu> ... second: once you are authenticated (and say you get a token), then you can access various things, update them, etc., so there must be some way to specify what you can do
<deiu> ... the question is: where do we specify that? In LDP, in HTTP? How do we specify what the ACL privileges are?
<deiu> ... our wiki page has example we can build on
<deiu> ... we haven't gotten further on this because there wasn't a lot of enthusiasm in the group
<deiu> Arnaud: I agree with that part
<deiu> ... but we should not get sidetracked into discussing the solutions, but instead try to figure out the questions we need to ask ourselves
<deiu> Ashok: does fine-grained ACL means access to one attribute?
<deiu> Arnaud: yes
<deiu> Ashok: people also want access to a group of resources, and to specify that group is hard
<deiu> Arnaud: that's not what we're trying to decide now
<deiu> ... now we want to know what the requirements are
<deiu> ... let's look at the doc together and decide how we can improve it
<deiu> ... why don't we go through the use-cases first?
<deiu> Arnaud: do people agree that the use-case involving ACL for group is important?
<TallTed> generic requirement: granting access to a (group of) resources to attendees of a particular session at a conference
<TallTed> Requirements: group entitites; grant permissions to the group; set permissions on a (group of) resources
Ted: Granularity of access control is important
<TallTed> Requirement: Grant permissions for (set restrictions on) individual (enumeration) entity/resource.
<TallTed> Requirement: Group entities/resources by enumeration (closed ended.)
<TallTed> Requirement: Group entities/resources by attribute (open ended.)
Arnaud: Do we need 3.3?
Ted: Disagrees
... that it should be removed
Usecase: Ted wants to access/update some resource ... he wants his friends to get acess ... he wants to acess related resources
Ted: Change title of 3.4
Andre: Do we need access control
in LDP?
... underlying store will have policies
... how to expose these policies to client
Ted: Talks about distinction between usecases and requirements
Alexandre: Is there anyting special about access control for LDP?
Ted: Is there a system that
satisfies these requirements?
... there is no W3C spec that tells us
<TallTed> Question: Granularity. LDPC? LDPR? attribute within LDPR ("triple level")?
Steve: We have application-specific access control
<nmihindu> people who are doing similar things today with Linked Data without LDP (Victor from UPM, Serena from Inria) do it as dataset, graph, triple levels as far as I know
<codyburleson> We should escape Identification and Authentication. We need only a URI to represent ANY Principal. Once we have that, we can focuse specifically on Authorization and make no claim about how the Principal URI is derived.
Andre: We use Web Acess Control to specify policies ... LDP just uses them
<TallTed> Access Control == Identification (e.g., WebID, Username, OpenID) + Authentication (e.g., WebID+TLS, Password, Password+Token) + Authorization (permissions, policies)
Ashok: The question is -- Is Access Control our problem
Steve: If we don't do it, who will do it?
<ericP> if resources can look different, you enable fine-grained access control.
Ashok: Should we write this as a charter for a WG?
Andre: There is a lot of work to be done here
<ericP> (i don't think there's anything that says that can't be different, though HTTP purists may argue that two representations with different triples can't represent the same resource at the same time)
Ashok: #.5 follows from 3.4 ... part of 3.4 actually
<codyburleson> Problem Statement: Any platform for developing web applications would be incomplete without a mechanism for Authentication and Authorization. Without this functionality, the platform could serve only light, utilitarian purposes at best. Without security, it would not even be proper to call the system a "platform".
<Zakim> ericP, you wanted to ask whether an LDP Resource can have different triples (or Container have different members) depending on the authentication
Eric: Is there something in LDP that depends on auathentication?
Ted: Nothing says two user have to see the same thing
Andre: Let's ask folks who have implemented access control to send usecases
Sandro: I like very specific
usecases
... 3 paras that would define scope of work in a charter would
be good
s/\sandro/sandro/
<codyburleson> +q
<codyburleson> -q
Move last usecase to intro section
Move 4.2 to section 5
Arnaud: Do we need section
5?
... move to other document?
Sandro: Start another wiki page with the 3 paras that could go into a charter
Ted: make that the conclusion of this document
Arnaud: Yes
Nandana, do you have a comment?
<nmihindu> Ashok, no I've just put my mind completely to the primer :)
Great!
<BartvanLeeuwen> break now ?
<TallTed> break until 10:35 local
<sandro> topic; json
<sandro> issue-97
<trackbot> issue-97 -- Json instead of (in addition to?) turtle -- raised
<trackbot> http://www.w3.org/2012/ldp/track/issues/97
Arnaud: We could put in Best
Practices doc.
... don't want to go to another Last Call.
... We could put a SHOULD in the spec. We can do this w/o going
to another Last Call
<codyburleson> +1 "SHOULD" support JSON-LD
<ericP> imo, that's n'th last call
PROPOSAL: Add SHOULd support
JSON-LD in spec
... we can also add "who supports JSON-LD" when we go to CR
Sandro: Are we saying need to
convert formats?
... need translation on output or store both formats
Steve: Or say you match the format of request
<betehess> my take: MUST Turtle / SHOULD JSON-LD does not sound like a so great idea. not sure that it solves exactly
Sandro: We should gather data to
go into Director meeting
... We will put in spec ... if Director obejcts move to BP
Eric: Can we put into separate doc that put to REC
Sandro: One line ... too much hassle
Eric: There is mapping from
JSON-LD to Turtle .... 1 to m mapping ...
... need context
Sandro: We only support JSON-LD which has context embedded in it
<ericP> right, but that's a mapping from json to one namespace unless you want to use the very ugly json-ld with no short names
Alexandre: Discussion about where SHOULD goes
<ericP> (Sandro)
Alexandre: also SHOULD vs. MUST
<sandro> ericP, no, the servers and the clients get to figure out the @context to use
Steve: We may have to go to
another call if we get significant comments in CR.
... so we can put in BP and then add to spec later
Sandro: Let's ask director. If he says NO we move to BP.
<ericP> sandro, ahh, so we don't ahve a standard serialization in json
Arnaud: can we add to AT RISK
Sandro: Maybe
<betehess> betehess: if there was no LC issue, I would like to see MUST implement JSON-LD (no Turtle mandatory)
<roger> +1
<deiu> +1
Ashok: You are making a marketing asessment
Sandro: Clear that JSON has market ... not clear if JSON-LD has market
Arnaud: We are not forcing servers to convert ... it's a SHOULD
Ted: MUST for both format is best
<sandro> PROPOSED: Close issue-97 with adding JSON-LD as a SHOULD in the spec, if we can in W3C process without another Last Call; if it'll require another LC, then we advocate for it in BP.
Arnaud: We can put a SHOULD for JSON-LD in spec or put in BP
<codyburleson> There is a marketing factor at play here that shouldn't be discounted. Turtle is meaningless to the "average" web developer. JSON-LD provides an option that is meaningful for them. If we want to successful, we need to appeal to the broader audience. So, I agree that is SHOULD be in the spec; not BPs.
<TallTed> +1
<BartvanLeeuwen> +1
<codyburleson> +1
<MiguelAraCo> +1
<SteveS> +1
+1
<sandro> +1
<deiu> +1 (just to help with adoption, but I would rather see a MUST instead)
<roger_> +1
<JohnArwe> +1
<MiguelAraCo> (I agree with deiu)
<ericP> -.1 # i'm uncomfortable engouth with sneaking this in after LC to whine about it, but not uncomfortable do something else
<betehess> +0
<sandro> RESOLVED: Close issue-97 with adding JSON-LD as a SHOULD in the spec, if we can in W3C process without another Last Call; if it'll require another LC, then we advocate for it in BP.
Some leaning towards MUST
Arnaud: There are different
solutions but have no agreement on requirements
... and usecases
Sandro: Need to be able to patch from any graph to any graph and you need every patch to be tractable
<sandro> (those are my constraints, other people have others)
<SteveS> Some prior discussion: Use Cases http://lists.w3.org/Archives/Public/public-ldp-patch/2013Sep/0000.html
<Arnaud> https://docs.google.com/presentation/d/1snLP7U97q7wgtsHznnP-RRuAndZNwFytU6q-lrO8U6A/
<SteveS> Requirements: http://lists.w3.org/Archives/Public/public-ldp-patch/2013Sep/0016.html
Alexandre presents slides
<sandro> https://www.w3.org/2012/ldp/wiki/LDP_PATCH_Proposals
SPARQL patch+skolemization, SPARQL patch w/o skolemization, RDF Patch
<SteveS> JSON Merge Patch http://tools.ietf.org/html/draft-ietf-appsawg-json-merge-patch-02
Ashok: Issue with patching large arrays
Web Payments using JSON-LD and JSON patch
Arnaud: Are you agruing for RDF Patch?
Alexandre: Yes
Sandro: Easy if you don't have
blank nodes. So I said use Skolemization.
... Eric argues that Skolemization is expensive
... You could serialize triples to add and triples to delete in
Turtle
<Zakim> SteveS, you wanted to ask if there really is a single universal solution for patch
Discussion about blank nodes can be identified
Arnaud: Either we agree to something that's not perfect or we have no solution at all.
<sandro> Pick your poison: blank-node-identifiers or worst-case-fails
Steve: My usecase is more towards a lightweight RDF Patch. Limited requirements.
Ashok: Alexandre, is there a document we can point to?
<Zakim> sandro, you wanted to say where LDP *needs* patch (huge containers)
Sandro: What do LDP users really
need?
... add/delete triple from huge graph ... no blank nodes
... cannot use PUT
<betehess> Arnaud, define "big" :-)
Discussion about Skolemization and how expensive it is
<sandro> sandro: One could also do a nice, efficient streaming protocol for maintaining sync
Arnaud: This seems to be brainstorming. How to we make progress? Can we reach a compromise?
Sandro: Requirement: There is a
big graph in a triple store and you want to change a few
triples in it
... must be able to patch any graph
<betehess> also, remember that there will be a time to see what is supported in implementations... who is planning to implement one of the solutions?
<betehess> question: do we want to be able to patch _any_ graph? or do we think "realistic" (define realistic) graphs are just ok
<Arnaud> STRAWPOLL: a) I'd rather keep it simple and accept a limited solution, b) I want a general solution and am willing to accept the additional cost
<betehess> strong a)
<ericP> this puts universality and tractibility at odds
<TallTed> require universality; require tractability; require both; require neither...
<sandro> STRAWPOLL: If we suggest one PATCH format, we make it (a) fail on certain pathological graphs, or (b) require the server to maintain Skolemization maps
<betehess> sandro, that's not a strawpoll, that's a fact
<sandro> :-)
<betehess> my answer: yes :-)
<sandro> STRAWPOLL: If we suggest one PATCH format, we make it (a) fail on certain pathological graphs, or (b) require the server to maintain Skolemization maps. Vote for which branch you'd rather live with;
<sandro> STRAWPOLL: (Assuming we suggest one PATCH format) should it (a) fail on certain pathological graphs, or (b) require the server to maintain Skolemization maps.
<Arnaud> STRAWPOLL: I'd rather have a solution that (a) doesn't address certain pathological graphs, or (b) requires the server to maintain Skolemization maps
<betehess> strong (a)
<deiu> a) I don't want to pay a high price every time, regardless of case (while also maintaining skolemized versions), AND because I also want to do the PATCH operation in one request
<ericP> a
<sandro> -1 go to lunch :-)
<SteveS> a +1, b -0 [we do a) first and can do b) later if needed]
<ericP> OBJECT
<deiu> a) +1, b) +0
<sandro> a -0, b +0
<ericP> a +1, b -.5
<MiguelAraCo> a) +1
<betehess> (a) +1 (b) -.9
<BartvanLeeuwen> a) +1
<JohnArwe> a +1, b (if needed as fallback) +0.5 ... I would prefer a better understanding of which graphs are considered pathological
<roger> (a) +1, (b) -0.5, but, mostly plan on using domain specific ways to do PATCH like things
a
<TallTed> general solution for all but pathological case; once that's recognized, fall back to Skolemnize
<codyburleson> a) +1
Sandro: Still question on expressiveness
Alexandre: Do we want to handle blank nodes or not
Eric: Question is whether you
have variables and xxx
... Not hard to produce a spec on SPARQL patch
<Arnaud> lunch break until 12:45 local
<BartvanLeeuwen> enjoy lunch
<ericP> i'll see your mutation and raise you a departure
BREAK UNTIL 1PM EASTERN
<JohnArwe> i.e. for ~51 mins
<BartvanLeeuwen> thats gone be a quick dinner for me ;)
<deiu> scribenick: deiu
Arnaud: resuming meeting
... we can spend 1h on PATCH and maybe another hour on
paging
... the poll was a useful exercise, so now we know what are the
problems we need to solve
... the question is: is there a solution?
... what can we agree on to make progress?
betehess: we have two solutions: ericP's (with BGP) and Pierre-Antoine's solution
sandro: what about RDF patch?
betehess: it needs skolemization
sandro: Tim's is not expressed in concrete terms...
betehess: that's basically ericP's solution, with additional constraints
Arnaud: let's have a straw poll on these two options
sandro: the big difference is
that one feels like SPARQL and the other one doesn't
... "feeling" like SPARQL is a negative point for LDP
adoption
<betehess> solutions are: ericP's SPARQL Update with constrained BGP vs Pierre-Antoine's RDF Patch + property path
<Arnaud> STRAWPOLL: pursue a) ericP's (with BGP) or b) Pierre-Antoine's solution
a) 0 b) +1
<roger> a) -0.5, b) 0.5
<betehess> a) +0 (not disagreeing with ericP's view) b) +1
<sandro> a -0.5 b 0.5
<TallTed> a +0.5 b +0.25
<SteveS> a) +.1 b) +.9
<Ashok> 0, 1
<MiguelAraCo> a) +0.5 b) -.5
<Zakim> betehess, you wanted to comment on syntax
<betehess> Arnaud: we are not married to this syntax, could be JSON
Arnaud: what do we take from
this?
... the majority seems to prefer b)
... what's the status of PA's proposal? is it written
somewhere?
betehess: no, it isn't, but I
plan to do it
... I can also provide a test suite and implementation
Arnaud: do we agree this is the
next step? (start drafting the PATCH spec)
... then we have consensus
sandro: we can make it a REC track
Arnaud: there's a big difference, not just in the outcome but in what we do towards it
<betehess> LD Patch
Arnaud: how do we name it?
betehess: the full name can be "LD patch format" and the short name can be "LD patch"
<betehess> Linked Data Patch Format, would live at http://www.w3.org/TR/ld-patch/
<sandro> Linked Data Patch Format
<betehess> Linked Data Patch Format, would live at http://www.w3.org/TR/ld-patch/
<sandro> ldpatch
<sandro> ld-patch
<sandro> PROPOSED: We encourage Alexandre to draft a Linked Data Patch Format, along the lines of Pierre-Antoine's proposal
<SteveS> +1 (encourage yes, require/mandate is even better ;)
+1
<nmihindu> +1
<sandro> +1
<TallTed> +1
<betehess> +1
<Ashok> +1
<roger> +1
<codyburleson> +0
<betehess> /me feels encouraged
<sandro> RESOLVED: We agree to draft a Linked Data Patch Format, along the lines of Pierre-Antoine's proposal
Arnaud: the resolution is that as
a group we will start working on PA's proposal, while betehess
will write it down in the document
... now betehess can take an action to do it
... then we're done with PATCH for today!
<betehess> ACTION: betehess to draft a Linked Data Patch Format, along the lines of Pierre-Antoine's proposal [recorded in http://www.w3.org/2014/04/17-ldp-minutes.html#action01]
<trackbot> Created ACTION-139 - Draft a linked data patch format, along the lines of pierre-antoine's proposal [on Alexandre Bertails - due 2014-04-24].
Arnaud: I think everyone's happy with this
Arnaud: Ashok has a proposal for us
Ashok: it looks we're not
agreeing on one solution right now
... most solutions have caveats
... so we could add a warning, saying that if you do paging,
the collection may change
Arnaud: I think we have agreed
that we can do better
... today we're not providing any mechanisms in that
regard
... yesterday we were left with 2 options: what we have in the
spec + notification (which doesn't stop the client from
continuing); the second option was to pursue sandro's
proposal
TallTed: adding this editorially to the existing spec makes it clear what you get
sandro: it's clear in the spec
that it is lossy
... the spec has the word "lossy"
Arnaud: so basically sandro wants
to veto this
... we've agreed that we will do the notification (which is
supposed to be mandatory) so the clients know if there was a
change during paging
sandro: ok, I can live with that
<sandro> WARNING: YOU MIGHT NOT SEE INSERTIONS OR DELETTIONS THAT MIGHT HAPPEN DURING PAGING.
<sandro> +1 that's all I've ever asked for.
<TallTed> we do also have -- 7.1.1 A LDP client SHOULD NOT present paged resources as coherent or complete, or make assumptions to that effect. [RFC5005].
<sandro> (because it implies you WILL see triples that are there the whole time)
Arnaud: triples that were there
when you started and are still there when you end, are
definitely seen by the client
... this is a clarification of how lossy paging is
sandro: is everyone ok with the wording?
TallTed: I'm not ok with any wording so far
sandro: are you ok with having test cases that cover the lossy behavior?
<SteveS> Anyone have a reference to a source code copyright/license header for W3C test suites?
TallTed: if I'm on the page with items 11-20, and someone deletes 19, what is the first item on the next page?
sandro: I would like to have a test case for those cases
Ashok: if the server remembers
the first and last triples it displays, then if you do a
delete, then it's ok
... so the triples won't move around between pages
TallTed: things will appear to
shift if you scroll back and forth (or if you reload the same
page)
... if you reload the same page you may not see the same data
(same for scrolling) -> these are the warnings
Arnaud: people are starting to
see the value in sandro's proposal
... we still need to agree on how to word it
... I think the lossly aspect is especially important in the
case where the client doesn't choose when things get paged
Ashok: when the client starts to page, it caches the collection and then pages over the cache, but it may not have enough space
<TallTed> PROPOSAL: Spec Sandro's paging proposal (link next based on last record shown on current page; link prev based on first record shown on current page); include warnings that reloading any "page" may not deliver same data as previous load of that "page". Full one-way traversal will show every record that is there at commencement and remains throughout; records added or deleted (even if re-added) during traversal may not be shown as
<TallTed> such. All pages should be tagged NoCache.
[people don't like the NoCache bit]
<TallTed> PROPOSAL: Spec Sandro's paging proposal (link next based on last record shown on current page; link prev based on first record shown on current page); include warnings that reloading any "page" may not deliver same data as previous load of that "page". Full one-way traversal will show every record that is there at commencement and remains throughout; records added or deleted (even if re-added) during traversal may not be shown as
<TallTed> such. Caching flags TBD.
<TallTed> PROPOSAL: Spec Sandro's paging proposal (link next based on last record shown on current page; link prev based on first record shown on current page); include warnings that reloading any "page" may not deliver same data as previous load of that "page". Full one-way traversal will show every record that is there at commencement and remains throughout; records added or deleted (even if re-added) during traversal may not be shown.
<SteveS> +1
<sandro> +1 as long as we're clear this is really an implementation technique, and the key point is the underlying invariant
<betehess> +0
<Ashok> +1
+0.9(9999)
<TallTed> +1
<roger> +0.8
<SteveS> +next
<nmihindu> +1
<BartvanLeeuwen> +1
<MiguelAraCo> +.5
<MiguelAraCo> +0.5
<sandro> sandro: for eample, you could have pages that are determined by the content
Ashok: suppose I don't care about updates and I just want to page, and if the contents change then I'm ok with it, then am I allowed to do that?
<Arnaud> RESOLVED: Spec Sandro's paging proposal (link next based on last record shown on current page; link prev based on first record shown on current page); include warnings that reloading any "page" may not deliver same data as previous load of that "page". Full one-way traversal will show every record that is there at commencement and remains throughout; records added or deleted (even if re-added) during traversal may not be shown.
<Arnaud> STRAWPOLL: I prefer paging to be controlled by a) the client b) the server
<sandro> sandro: If the server wants to implement by doing a snapshot, it's welcome to. That meets the invariant.
sandro: the client sends a "preferred page size header" to initiate paging
<sandro> sandro: it's not aboiut the client being resource limited, so much as the client wanting to focus on a particular bit.
<Arnaud> STRAWPOLL: I prefer paging to be initiated by a) the client b) the server
<Ashok> a)
<TallTed> c - either
a)
<sandro> a
<betehess> c - potentially both
<sandro> How about: Prefer: Page-Size-KB=100
<sandro> How about: Prefer: Page-Size-KB=unlim
=*
<sandro> sandro: Is it the case that the client MUST understand paging?
<sandro> STRAWPOLL: The server MAY do paging even if the client hasn't asked for it
<sandro> (today in the spec, means the client MUST understand paging.)
<sandro> (as in the spec today)
<TallTed> +1
<SteveS> +1
<Ashok> +1
<sandro> +0
-0.9
<MiguelAraCo> +1
<BartvanLeeuwen> +1
<betehess> +1
<codyburleson> +0
Arnaud: so we have consensus
<sandro> STRAWPOLL: We'll allow for clients to ask for paging, ask for no paging, and ask for page size
Arnaud: we can talk about page sizes or no page, or what are the preferences the clients can convey to servers
<TallTed> +1
<SteveS> +0 (could defer until a LDP.next)
+0 (same as SteveS)
<betehess> +0
<nmihindu> +0.5 (would nice to have if possible)
<Ashok> +1
<roger> +0.5
deiu: paging can be replaced by sorting+filtering+limit+offset
Arnaud: filtering is pretty complicated
betehess: what about the scope of bnodes between pages
Arnaud: the client should have a say regarding the paging preference
<TallTed> HTTP code 413 Payload Too Large -- as a result of the client asking for max-result=10KB + whatever request
roger: you could SPARQL to page
over the results
... we can use subsets of SPARQL for paging and/or patch
sandro: if a clients says "I want
the top 10 items", it also knows more about the shape of the
graphs than the server
... there could be a "group by subject" clause to define the
items that will be returned
Arnaud: I still think the best way is to allow the client to say "I want paging" or "I don't want paging"
[sandro propses a way to do paging over periods of time - i.e. sending data over 100 ms ]
SteveS: we couldn't come up with
something that made sense in OSLC
... small/medium/large are very relative
sandro: then what about time? (if size in kb is not good)
betehess: if you're the client,
then you do paging based on a rough idea of the ration between
the triple and the size
... so I guess the triple is fine
Arnaud: people are now saying that maybe we can give a page size in triples
<sandro> PROPOSED: We'll provide a way for the client to express a desired page size hint to the server, including whether or not to do paging at all
<sandro> PROPOSED: We'll provide a way for the client to express a desired page size hint to the server, including whether or not to do paging at all. Size in number of triples, but we know the server might be doing associated-chunks of triples, like around a blank node, or the same container item.
+1
<TallTed> +1
<betehess> +1
<SteveS> +1
<Ashok> +1
<BartvanLeeuwen> +1
<nmihindu> +1
<sandro> +0.5 (only because number-of-triples isn't the right metric)
<Ashok> Roger: +1
<sandro> PROPOSED: We'll provide a way for the client to express a desired page size hint to the server, including whether or not to do paging at all. Size in number of KILOBYTES, but we know the server might be doing associated-chunks of triples, like around a blank node, or the same container item.
<sandro> +1 :-)
<betehess> -0.1
0
<SteveS> 0
<TallTed> +1
<Ashok> -1
<roger> 0
<BartvanLeeuwen> 0
<codyburleson> 0
<Arnaud> RESOLVED: We'll provide a way for the client to express a desired page size hint to the server, including whether or not to do paging at all. Size in number of triples, but we know the server might be doing associated-chunks of triples, like around a blank node, or the same container item.
Arnaud: we can discuss the
details later
... are there more issues re. paging?
... we have tackled the most important ones
<sandro> how about: Prefer: Page-Size=100
<sandro> and Prefer: Page-Size=* (for no paging) or Page-Size=No-Paging
Ashok: do you want to add membership triples to the top of the page?
sandro: I think there are one per item (one membership and one containment)
<sandro> PROPOSED: If a Container has membership triples and containment triples included, the membership triples and containment triples MUST be on the same page as each other.
<sandro> PROPOSED: If a Container has membership triples and containment triples included, the membership triples and containment triples for a given resource MUST be on the same page as each other.
<sandro> arnaud: No one is going to have the triples on the same page.
<sandro> PROPOSED: If a Container has membership triples and containment triples included, the membership triples and containment triples for a given (contained/member) resource MUST be on the same page as each other.
<sandro> arnaud: No one is going to have the membership and containment triples on the same page.
<TallTed> +1
0
<sandro> +1
<SteveS> -0.1 (let impls do what makes sense for triples they have)
<betehess> +0 (not sure how useful it is)
<sandro> RESOLVED: If a Container has membership triples and containment triples included, the membership triple and containment triple for a given (contained/member) resource MUST be on the same page as each other.
<roger> +0.5
<Ashok> +1
Arnaud: I think we have achieved
a lot!
... people are welcome to stick around for interop testing
<BartvanLeeuwen> :)
Arnaud: let's adjourn the
meeting
... on Monday I will host an informative call
... next formal meeting is on the 28th, when I expect all
drafts to be ready
<Arnaud> adjourned
<sandro> woo hoo!
+1
<Arnaud> trackbot, end meeting
This is scribe.perl Revision: 1.138 of Date: 2013-04-25 13:59:11 Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/ Guessing input format: RRSAgent_Text_Format (score 1.00) Succeeded: s/is/it/ Succeeded: s/Use Case: granting/generic requirement: granting/ Succeeded: s/Wen/Web/ FAILED: s/\sandro/sandro/ Succeeded: s/\Sandro/Sandro/ Succeeded: s/ti/it/ Succeeded: s/LD Patch Format/Linked Data Patch Format/g Succeeded: s/We encourage Alexandre/We agree/ Succeeded: s/+limit/+limit+offset/ Succeeded: s/know/knows/ Found ScribeNick: Ashok Found ScribeNick: deiu Inferring Scribes: Ashok, deiu Scribes: Ashok, deiu ScribeNicks: Ashok, deiu Default Present: codyburleson, BartvanLeeuwen, nmihindu, Arnaud, Ashok, betehess, JohnArwe, roger, sandro, SteveS, TallTed, deiu, ericP, [IPcaller], [IBM] Present: codyburleson BartvanLeeuwen nmihindu Arnaud Ashok betehess JohnArwe roger sandro SteveS TallTed deiu ericP [IPcaller] [IBM] WARNING: No meeting chair found! You should specify the meeting chair like this: <dbooth> Chair: dbooth Found Date: 17 Apr 2014 Guessing minutes URL: http://www.w3.org/2014/04/17-ldp-minutes.html People with action items: betehess[End of scribe.perl diagnostic output]