See also: IRC log
<trackbot> Date: 15 April 2014
<sergio> guys, I cannot be all time connected by phone, at least today
<sergio> so ping me if you need somethign from me
<Arnaud> hi everyone
<sergio> I'll try to connect for tomorrow and the test cases slot
<Arnaud> we're still getting set up here
<sergio> ok
<Arnaud> we forgot to reserve the phone bridge so the code is 26631 instead of the usual ldpwg
<sandro> video link for meeting -- http://bit.ly/swa-hangout
<betehess> scribenick: Alexandre
<betehess> scribenick: betehess
<scribe> scribe: Alexandre
Arnaud: got a request from
nandana to move the Primer
... so I swapped Primer and BP
... let's get started
... want to talk where we are
<scribe> ... finished 2 LC period
UNKNOWN_SPEAKER: few comments,
not too many
... we have to dispose of them properly
... be prepared for the review w/ w3c management for later
phases
... comments are part of the review
... good to have some comments: people have looked at it!
... we do best effort to satisfy the comments
... a bit confused with the tracker
... I forward the comments to the list but they don't appear in
the tracker
... need a plan for addressing the comments before leaving the
meeting
... I was at WWW last week
... *many* people came to me to ask me the status of the
spec
... the community is waiting for it
... we split the spec
... and make sure everybody wants it
... UC&R was republished as a Note
... we won't talk about it unless you ask
... test suite and validator will be important for CR
... so we'll spend time on it
... we have to show the spec can be implemented
... Access Control WG Note: there will be 1 hour
... it was part of the Charter
... we may not do it, just have to explain
... BP&R was not in charter but we have moved some stuff
there
... Primer is important
... part of the feedback I had was about readibility of
spec
... so the Primer is key
... and then, what's next?
... we had a request from W3C to know if we'll meet at
TPAC
... end of WG supposed to be in June
... don't we'll be done in June
... at best, we're in PR
... which means we're pretty much done
... but we have to stick around, (like 2 months) just in case
there are comments
... extension would be under same charter
... but the group may want to continue the work
... then there would be a _new_ charter
... we have a page for wishlist for LDP Next
... so we'll discuss what we want
... W3C needs to allocate resources, based on what's in the
charter
... succeeding with the first charter is the best way to get
another one ;-)
... last but not least: Patch format
... the spec says you have to use Patch
... but we don't say how
... we created a separate ML
... had some mails, but not much
... hope we can have a resultion on that
<nmihindu> thank you very much
SteveS: ericP will participate to the Patch conversation
<JohnArwe> if you're speaking nandana, we're not hearing you, fyi
<SteveS> from F2F5 wiki: “ericP (though I can attend occasionally, possibly for patch)”
<nmihindu> JohnArwe, I am trying to fix the mic, please move on.
Arnaud: people were interested in
interop testing
... don't know how feasible it is
... last afternoon is dedicated in doing that
... not sure how I'll make it happen
... if there is any prep before we do it, please let me
know
... based on the discussions we'll have, I won't hesitate to
shrink/extend time on some subjects
sandro: btw, the catering is provided by QCRI
Arnaud: thank you
... hard to know how much time we'll need
SteveS: was wondering haw many people we'll have implementations
Arnaud: around 4?
TallTed: all servers I guess
deiu: have a client as well
TallTed: curl is test suite, it's not interop
sandro: it's an alternative
Arnaud: ok I see the point
TallTed: I don't consider curl as an LDP client
Arnaud: ok, let's jsut call it
"testing"
... interop is reached when you can replace a component with
another one
<deiu> http://www.w3.org/TR/2014/WD-ldp-20140311/
<TallTed> http://www.w3.org/2006/02/lc-comments-tracker/55082/
<TallTed> http://www.w3.org/TR/2014/WD-ldp-20140311/
<codyburleson> Do we need to engage the teleconference bridge? Right now, +1-617-761-6200, conf. code 53794#, returns "This passcode is not valid."
<sandro> codyburleson...
<sandro> codyburleson, code is 26631 for today, and there's a video-only link http://bit.ly/swa-hangout
Arnaud: trying to figure out how
the tracker works
... there were 2 comments from reto
... one about multiple named graphs
... thanks betehess for that one!
<Arnaud> http://lists.w3.org/Archives/Public/public-ldp-comments/2014Mar/
Arnaud: and then the null
relative URI "hack"
... and then there is an extra one
... an issue we have to fix
... brought up by sergio
... there is a problem with the use of the rel=describedby
header
... for 2 different things
<Arnaud> http://lists.w3.org/Archives/Public/public-ldp-wg/2014Mar/0037.html
Arnaud: has anybody anything to add?
SteveS: had a comment about implementation feedback needing more clarity
Arnaud: people need to forward
comments to the list
... so that we can track them
sandro: external comments are still important for reviews
Arnaud: let's agree we have 1
issue and 2 comments
... and we need to make sure we have done the same for comments
from 1st LC
... timbl's comments are marked as ?? but we are in an ongoing
discussion with him
... mark baker said he's fine with the improvements we
made
... are we in good share re: comments? do we need to do
more?
... note that we haven't had a real answer from timbl
... and there is a comment not really addressed
sandro: timbl may join us 1 hour,
we can ask at this point
... in good shape? would be good to have more feedbacks from
implementers
... having that by email is better
Arnaud: Q for editors:
<Arnaud> http://www.w3.org/2006/02/lc-comments-tracker/55082/ldp/2840
[[ 4.1 "burden of constraints for resource creation" - I feel that phrase needs more explanation ]]
JohnArwe: still part of the spec
TallTed: the question is "what do
you mean?"
... not clear at first read
[ people discussing possible resolutions ]
sandro: how about: how can the server make it easy for the client to create resources?
Arnaud: sounds nice
... do we agree?
... with editorial change?
... would allow us to dispose of that pending comment
<TallTed> +1
+1
<deiu> +1
<MiguelAraCo> +1
scribe: I don't hear objections
<sandro> +1 :-)
<codyburleson> +1
Arnaud: now we start with the null relative URIs hack comment
<nmihindu> +1
Arnaud: let's try restate what
the issue is
... when we create a resource
... we send some RDF
<sandro> action-137?
<trackbot> action-137 -- Sandro Hawke to Contact yves and erik to make confirm with them that http-wg is okay with this reading of the link context -- due 2014-04-07 -- OPEN
<trackbot> http://www.w3.org/2012/ldp/track/actions/137
Arnaud: at that time, we don't know what the url of the resource will be
Arnaud: so we use the null
relative uri
... and everything is relative to it
... comment says: doesn't exist in RDF
... as RDF does not support this notion
... alternative is the client know the url before posting
... so there are 2 steps
JohnArwe: there are other
solutions
... could have a placeholder
... eg using a header to specify a place holder
Arnaud: this was presented as an alternative
sandro: it's not a bnode, it's a node uri
TallTed: it behaves like it
Ashok: RDF does not have the concept, can we fix it?
sandro: we can use relative graphs, not rdf graphs
Arnaud: hold on
... this was proposed as alternatives
JohnArwe: you need to specify uri for the placeholder
betehess: then the graphs are not isomorphic
Arnaud: issues is coming from
people using libraries without relative uris
... people claim their tools don't support it
TallTed: if the problem is the library, go fix the library
<ericP> RDF doesn't support it
<ericP> i'd like it to, but RDF is all about absolute URIs
Arnaud: RDF does not support it,
my tools don't support it, what can I do?
... one possible response: LDP uses Turtle, which support rel
uris
<deiu> betehess: I reported this issue a long time ago, saying that by changing from RDF mediatypes to something new (eg. application/ld) would help
<deiu> ... we can add something to the recs, telling the RDF processor to use a special namespace for the relative URIs and then you do the interpretation
<deiu> ... this is a way to deal with libs that don't support relative URIs
<deiu> sandro: I don't understand
<deiu> ... the client has no way to construct a turtle serialization
<ericP> new URI scheme!
<deiu> ... both problems exist, the server has the problem that it cannot properly parse turtle
<ericP> client uses a uri scheme which is understood to be changed by the server
<ericP> server, in the worst case, parses twice
Arnaud: several options: either we stick with what we have
<ericP> could also say that ldp:foo is the base URI
<deiu> betehess: if you want to actually tell people that it's not exactly RDF we're working with
Arnaud: we can create a note on
relative graphs
... or we just leave it as is
... or we use some placeholder uris that the server can
recognize
... or we give some control to the client to choose their own
rel uri
<ericP> interesting, we could use the slug for that (or some transform for that)
deiu: can't we use the Slug as the placeholder?
<sandro> OPTION 1: When the client wants to post a graph including self-reference, it MUST use the null-relative URI as the reference to itself. We clarify the spec, etc.
<sandro> OPTION 2: When the client wants to post a graph including self-reference, it MUST use some magic URL we pick, eg http://www.w3.org/ns/ldp#self
<sandro> OPTION 3: When the client wants to post a graph including self-reference, it MUST make up some placeholder URI, and tell the server which one it picked using Link: <placeholder URI> rel=selfReferencePlaceholder
TallTed: should not be an http
uri
... because you don't have control over it, it's a server side
thing
<ericP> the only requirement for the placeholder URI is that it have a sufficient number of '/'s
[discussing sandro's options]
sandro: the client doesn't know
the future "this" uri, that's the issue
... option 1 is what we have in LC right now
Arnaud: then we'd say "sorry, you
have to make it work"
... other options would require to change the spec
sandro: well processing is
different
... we'd need to ask every lib to fix that
TallTed: which side we're putting the burden on: client or server
<ericP> POST /containers/PeopleAndMovies << { ../foo a foaf:Person }
sandro: we may need a Relative Graph Note
Ashok: would it be helpful to other people?
<ericP> OPTION 1 is probably the easiest to optimize because the server doesn't ever have to crack potentially normalized IRIs
Arnaud: honestly, I am not really in favor in making new documents: too much effort
<sandro> A "Relative RDF Graph" is hereby defined as being just like an RDF Graph except that IRIs are allowed to be Relative IRIs, not just Absolute IRIs.
SteveS: there is always a
base
... meaning the client can communicate the base it wanted
... there is always some base
sandro: what you want is the Turtle serializer to make the graph relative to my own base
<sandro> And then we suggest tool makers include this concept in their APIs. EG Turtle serializers should have a way to serialize relative graphs.
<sandro> sandro: OR, lets just say RDF serializers SHOULD include a base parameter
ericP: betehess and I tried to use Jena back then, had to do some hack
betehess: situation is much better now, a few lines of code to have a proper serializer
sandro: may not speak about the relative graph, just say that we don't know the base
<ericP> "The POST or PATCH body may have relative IRIs. These IRIs are relative to the final document location. Note: Systems which parse the input document in order to determine the final document location may need to provide a temporary BASE (RFC3896) for parsing, determine the final document location, and parse the input again with that as the BASE
<ericP> ."
<sandro> Sandro: Let's NOT use "Relative RDF Graph", but instead use "Deferred-Base RDF Graph Serialization".
<sandro> ericP, what are you quoting?
<ericP> just proposing
Arnaud: if we didn't have the LC already, I would push for option 3
<ericP> but you probably have better text already, sandro
<deiu> betehess: I think we're just trying to make Reto happy
<deiu> ... I've always been thinking of relative graphs
<deiu> ... there is a time when we don't know the URI of the graph
<deiu> ... the LDP spec says the base URI will be chosen by the LDP container, so I don't see any issue
<sergio> guys, not sure if you are still dicussing the issue, but rdflib (python has the base for serilizers: http://rdflib.readthedocs.org/en/latest/apidocs/rdflib.plugins.serializers.html, and probably sesame (java) too:
sandro: problem with rel graph as a concept, it means we have something new to be handled by libraries
<JohnArwe> @sergio are you unsure b/c you're having trouble hearing us/
<deiu> betehess: libraries can be fixed today, and we stand to gain a lot more from using relative URIs
<sergio> JohnArwe: I'm not connected by phone, sorry
<ericP> i wouldn't call that "fixed". i'd call it "extended".
<ericP> pretending otherwise will irk the ire of RDF hackers
<JohnArwe> ah no worries - yes lots of discussion back and forth about value/not of "relative graph" definitions
sandro: the real question is being able to make a serialization relative to a certain base
<sandro> sandro: I don't think defining Relative Graph is a good idea, because it will make Jena, etc, think they should define serializers and parsers for this, would be be a waste.
<sandro> sandro: We want serializers to have a MakeRelativeToThis IRI parameter.
<sandro> serialize(outputStream, graph, makeRelativeToThis)
<sandro> and note that servers may need to parse zero, one, or two times, depending on their design.
Arnaud: we have to acknowledge the problem
<sandro> ... for very reasonable designs.
Arnaud: other people said this is a practical way to handle this situation (cygri, dwoods)
<TallTed> TallTed: or rather, we need to be able to tell serializers to make serializations with relative IRIs which refer to that serialization... so s/makeRelativeToThis/makeRelative[ToOutputStream]/
sandro: we can add the MakeRelativeToThis thing in best practices
Arnaud: then we don't do anything
in the spec?
... would be reasonable to add something
... the remark was based on how tools work, based on RDF is
defined
sandro: we could link from the spec to uc&r
<JohnArwe> not to uc&r, to best practices
Ashok: best practices is not normative
Arnaud: sounds like we're getting to an agreement
<sandro> "For a discussion of implementation issues around the use of relative IRIs during POST operations, see [BP]"
<sergio> +1
<sergio> I'll try to provide some practical examples of different libs
<sandro> great, sergio
PROPOSAL: we stick with the spec, add a pointer to Best Practices, and add an implementation issues relative to this
sandro: it'd be an informative dependency
<SteveS> BP https://dvcs.w3.org/hg/ldpwg/raw-file/default/ldp-bp/ldp-bp.html
Arnaud: errr, BP not published yet
sandro: or we can have a non-normative appendix in main LDP spec
<sandro> PROPOSAL: We stick with the current null-relative design, and we add a non-normative explanation of how that works, how to do it in some tools, etc, in a footnote, appendix, or (hopefully) BP.
<deiu> +1
<TallTed> +1
+1
<sandro> +1
<nmihindu> +1
<JohnArwe> +1
<MiguelAraCo> +1
<codyburleson> +1
<Ashok> +1
<roger> +1
<ericP> +1 (hope it works)
<sandro> RESOLVED: We stick with the current null-relative design, and we add a non-normative explanation of how that works, how to do it in some tools, etc, in a footnote, appendix, or (hopefully) BP.
<sergio> +1
<sergio> (late xD)
<sandro> :-)
<JohnArwe> @ericp, what part do you think might not work?
<ericP> @JohnArwe, can we claim a media type of text/turtle if we don't know the base at the time of transmission?
<ericP> i.e. should the client or an intermediary be able to know what graph was actually transmitted?
<sandro> So using .. is a Wrost-Practice, UNLESS you know how the Server is assiging URIs.
<ericP> JohnArwe, you see my issue?
<ericP> could i, as a client, have an automagically filled cache of stuff-i've-told-the-world?
<ericP> (probably not a show stopper use case, but does illustrate what goes wrong when you cheat on specs)
Arnaud: resuming
... during the discussion, somebody brought the ../
"problem"
... do we want to allow it? prevent it?
... what does it know? you don't know where the document will
be
JohnArwe: it cannot be a reliable way to reference the container
Arnaud: or even another resource eg. a sibling
TallTed: sure
... not necesseraly an issue
... can have multiple container having multiple paths
<nmihindu> Sorry. I thought I was already muted.
JohnArwe: interop could be limited
sandro: the ../ semantics is implied because of other specs
Arnaud: do we want to say
something about it in the spec?
... oh, the ../ issue was brought by cygri
<Arnaud> http://lists.w3.org/Archives/Public/public-ldp/2014Mar/0051.html
Arnaud: (may be discussed elsewhere as well)
[[
Because otherwise, it’ll be even less clear what “/“ or “/foo” or “..” refer to, as it’s unclear whether they will be resolved against your hack URI, or the container URI, or the new item URI.
]]
JohnArwe: rel uris is application specific
sandro: so the question is about
base uri, not just null uri
... the spec is already good
<sandro> 4.2.1.5 LDP servers MUST assign the default base-URI for [RFC3987] relative-URI resolution to be the HTTP Request-URI when the resource already exists, and to the URI of the created resource when the request results in the creation of a new resource.
SteveS: the spec is clear
... BP might help explaining further
Arnaud: so what are we doing?
nothing to do?
... add something in BP?
<sandro> "It follows from this definition that use of /../ and other non-null relative URI constructs during POST has application-dependent results"
JohnArwe: it's not ill-defined but it may limit interop
betehess: I'd need an example
where it limits interop
... it's not application or implementation specific. the spec
already says it's relative to the base uri, always defined in
LDP, even during POST
<sandro> "It follows from this definition that use of /../ and other non-null relative URI constructs during POST will cause the content to be referring to resources in a manner the client will not, in general, be able to predict."
betehess: but nobody can rely on it to refer to a parent or sibling
Arnaud: people presumed to know where the going to land in a POST and may use ../ in consequence
TallTed: why do we presume people will do that?
SteveS: we may handled that in BP
Arnaud: it's just somebody referred to that, would like to be able to point people at an good answer
roger: people will want to speak about hierarchy and may want to use ../ and stuff like that
<TallTed> "Other non-null relative URI constructs may not refer to the user's anticipated resource, due to variability in implementation and/or deployment. Tread with caution. Here be dragons."
Arnaud: let me make a proposal
<SteveS> roger, yes https://dvcs.w3.org/hg/ldpwg/raw-file/default/ldp-bp/ldp-bp.html#represent-container-membership-with-hierarchical-uris
<sandro> "It follows from this definition /../ URLs should not be used in POSTed content unless the client has additional information about IRIs are assigned."
Arnaud: we should agree to add something in the BP doc about the danger of POSTing docs using rel uris
<sandro> Add it BP that it follows from the specs that /../ URLs should not be used in POSTed content unless the client has additional information about IRIs are assigned.
deiu: you should never try to refer to a uri that will exist later
JohnArwe: we had a proposal to handle that in the BP doc
<sandro> PROPOSED: Add it BP that it follows from the specs that /../ URLs should not be used in POSTed content unless the client has additional information about IRIs are assigned.
JohnArwe: and we nail down the document
<sandro> PROPOSED: Add to BP that it follows from the specs that /../ URLs should not be used in POSTed content unless the client has additional information about how IRIs are assigned.
<sandro> PROPOSED: Add it BP that it follows from the specs that /../ URLs should not be used in POSTed content unless the client has additional information about how IRIs are assigned (by that particular server).
<JohnArwe> +1
<SteveS> +../1
<MiguelAraCo> +1
<sandro> +1
<nmihindu> +1
sandro: we can have an LDP extension using information that uris will be right under the container
<deiu> +0
-1
<sandro> betehess: i don't want people to consider the possibility that they MIGHT know more about how URIs are assigned by servers.
<TallTed> PROPOSED: Add to BP that it follows from the specs that using /../ URLs in POSTed content may have unpredictable results.
<sandro> PROPOSED: Add it BP that it follows from the specs that /../ URLs should not be used in POSTed content
<sandro> +1
<TallTed> +0
<JohnArwe> voting on sandro's...
<deiu> +0
+0 (can leave with it, strongly prefer TallTed's wording)
<JohnArwe> +0.5
<codyburleson> +1
<roger> +0
<nmihindu> +0.5
(we're currently voting on sandro's proposal)
<Ashok> 0
<SteveS> +0.5 (think a general section and discussion in BP on this general topic is good)
<Arnaud> PROPOSED: Add to BP that it follows from the specs that using /../ URLs in POSTed content may have unpredictable results.
<roger> +1
+1
<deiu> +1
<JohnArwe> +0.5
<sandro> +0
<TallTed> +1
<codyburleson> -1
<nmihindu> +1
<MiguelAraCo> +0
<SteveS> +0.5 (think a general section and discussion in BP on this general topic is good)
<TallTed> codyburleson - can you explain the -1?
<codyburleson> I just am uncomfortable with ../ in graphs
<codyburleson> period
<Arnaud> ok, thanks
Arnaud: then I think we'll go with sandro's proposal
<Arnaud> RESOLVED: Add it BP that it follows from the specs that /../ URLs should not be used in POSTed content
Arnaud: resolved!
<codyburleson> +q
Arnaud: should take care of all
relative uris
... that's the power you have: -1 is blocking
... that's how concensus should work!
... let's move to next topic: named graphs
<TallTed> http://lists.w3.org/Archives/Public/public-ldp-comments/2014Mar/0000.html
Arnaud: we added the sentence in
the spec lately
... in 5.2.3.4 [[ The created resource can be thought of as an
RDF named graph ]]
... some people thought it was a great improvement
... but other didn't like it, prefer to have one big graph
<codyburleson> -q
betehess: has anybody said anything about the default graph as union of named graphs?
sandro: don't think so
Arnaud: the sparql protocol does make use of named graphs
sandro: named graphs should rely on defining a dataset, which is not defiend
TallTed: the spec speaks about a preference to use a syntax supporting named graphs when `providing [a] resource and supporting containers in a single response representation.`
Arnaud: also related to inlining
<deiu> betehess: the reason I introduced the named graph discussion is that there are two things to consider: inlining and named graphs are very related
<JohnArwe> TimBL: historically lots of discussion about named graphs, what they should be, etc. when you bring in that term you tend to raise a lot of questions
<deiu> ... where can I look for info if I don't know where it is
<deiu> ... if I want to enable SPARQL for an LDPC, then how do I know which resources are members of a container
<deiu> sandro: that can be part of an extension
<deiu> betehess: the triple in question is ldpContains
<deiu> ... basically, you are able to point to the named graphs so therefore you can explore the container
<deiu> sandro: you can't backhand into SPARQL, LDP doesn't say that LDP is a dataset
<deiu> ... there is no way to get to SPARQL from LDP
<deiu> betehess: how do you define dataset?
<deiu> sandro: it's what you have in your SPARQL database
<deiu> ... LDP doesn't care about SPARQL, so it's out of scope
<deiu> betehess: nothing tells me today where the triples live
JohnArwe: we never said that implementations had to rely on named graphs
sandro: just saying that the
specification is not properly done when it comes to named
graphs
... I'd like to be able to do a GET with trig
... 2 options:
... 1. keep spec as is, and say we don't prevent him to have a
one graph implementation
... 2. we remove mentions of named graphs in the spec, and make
him happy
<sandro> sandro: Let's remove all usage of "Named Graphs" terminology in the spec, since we're not fully defining how it's all supposed to work.
TallTed: not forbidden use of
trig, it's still possible to return it
... if not supported, just return Turtle
... options are still there
Arnaud: are you saying you're speaking spec as is?
timbl: conneg must be used for
things that are the same
... so Turtle is not enough to return named graphs
TallTed: we said the server can
return more than you ask for
... so if you ask for trig, you just get more informations
timbl: would bad idea to return
trig without saying it's not a full representation of the
resource
... maybe a different http code?
... in LDP thing, the conceptual thing is a graph
sandro: in http, caching allows
to use headers for variance
... could use link headers, like Prefer
... meta point is: it's interesting work outside of this
WG
... let's not prejudge what the issue is
Arnaud: maybe we can remove
it?
... in terminology section, we have LDP-RS
sandro: can say it's a pair or IRI and graph in some dataset, but dataset is not defined
<TallTed> from RDF 1.1 Concepts -- "We informally use the term RDF source to refer to a persistent yet mutable source or container of RDF graphs. An RDF source is a resource that may be said to have a state that can change over time. A snapshot of the state can be expressed as an RDF graph. For example, any web document that has an RDF-bearing representation may be considered an RDF source. Like all resources, RDF sources may be named with
<TallTed> IRIs and therefore described in other RDF graphs."
sandro: was brought up by betehess saying that we have to clarify the spec
SteveS: timbl said we could just remove "named" from "named graph" because it is what it is
sandro: the problem is that it contradicts the RDF spec
Arnaud: yeah, it's a G-Box
timbl: the state of the resource is a graph
Arnaud: so removing "named" would work then
<sandro> The State of the Resource is a Graph, but the Resource itself is not a Graph.
<timbl> yes
Arnaud: the spec already speaks
about state
... the spec already speaks about state
<sandro> +1 An LDPR whose state is fully represented by an RDF Graph.
Arnaud: then let's go to
Examples
... we may remove the paragraph about syntax and multiple named
graphs
timbl: what's nice about LDP spec is that it defines solid things
<timbl> An LDPR’s state is an RDF Graph and is fully represented in RDF. See also the term RDF Source from [rdf11-concepts].
Arnaud: so the question from
SteveS was to consider moving that paragraph to BP
... I think it's fine
... we can remove the mention from 5.2.3.4
... just a hint here
... same for 5.2.4.2
... and that's it
<Arnaud> PROPOSED: removed references to named graphs: remove "named" in terminology section, remove paragraph in examples, remove sentence in section 5.2.34 and 5.2.4.2
<Arnaud> PROPOSED: remove references to named graphs: remove "named" in terminology section, remove paragraph in examples, remove sentence in section 5.2.34 and 5.2.4.2
<Arnaud> PROPOSED: remove references to named graphs: remove "named" in terminology section, remove paragraph in examples, remove sentence in section 5.2.3.4 and 5.2.4.2
<sandro> +1
<TallTed> +1
+0.99
<deiu> +1
<roger> +1
<SteveS> +1
<MiguelAraCo> +1
<codyburleson> +1
<JohnArwe> +1
<Arnaud> RESOLVED: remove references to named graphs: remove "named" in terminology section, remove paragraph in examples, remove sentence in section 5.2.3.4 and 5.2.4.2
<sandro> break until 1:15
<deiu> scribenick: deiu
<Arnaud> http://lists.w3.org/Archives/Public/public-ldp-wg/2014Mar/0037.html
<scribe> scribe: Andrei
Arnaud: when we POST a non-RDF
source, the server may create an additional RDF source (with
the meta data for the non-RDF source)
... to do that, we use rel=describedby
... Sergio raised the question about a possible conflict with
describedBy
sandro: we should say what happens when there are two headers
Arnaud: there is more than one thing that describes the resource, there's nothing wrong with that
sandro: basically they are all true, so the best practice would be to merge
Arnaud: for a non-RDF you
wouldn't have a shape
... you have a piece of XML, meta data and a schema
... you need to follow the link to find what kind of
information resource it is
... there is no way to guarantee that there will only be
one
sandro: if it's something very
specific, then you should sub-type the property
... we can change rel=describedby to rel=serverconstraints
Arnaud: resource shape was
submitted to W3C
... I expect discussion to start soon
... if I have a shape, I MUST use the rel=describedby link
sandro: I would like to take this
out
... 4.2.1.6 that is
... if the resource shape spec says something about this, then
we don't need to have it in the LDP spec
Arnaud: your client can figure out the constraints by following the link
sandro: I agree it works to follow the link and do conneg
Arnaud: you might end up using
two Link headers, it's not a big deal
... one Link might become deprecated at some point
TallTed: if you fail and don't say anything about the reason, then it's bad (as Timbl said)
sandro: unless there is something a client could do, why have the server provide the reason to the client
Arnaud: we can either drop or keep the Link, but if we keep it, what rel value are we going to use?
<sandro> OPTION 1: Use rel=describedby for as many things at once as needed; they are all types of description
<sandro> OPTION 2: Use different rel= arguments for each different type of description the client might find useful
Arnaud: Sergio said the "possible" conflict, when he referred to rel=describedby, and the one that is linking the binary resource to the RDF meta resource
JohnArwe: if you read the spec
carefully, then you would see there is no conflict
... some people may have a problem, others may not
sandro: how do you decide what is
meta data and what is data?
... these are the most important bits of the data, I don't want
to have another request to get the meta data
Arnaud: there's a tradeoff of reusing existing terms, but sometimes those terms are used to refer to different things
sandro: the resource shape will say "this kind of shape is allowed here"
<TallTed> { :thing rel=describedby :a . :a a ldp:resourceShape }
Arnaud: the spec is not really broken, we can live with the way it is so
<sandro> I kind of think OPTION 2 is better, long term, but OPTION 1 is fine, and in the spec already.
Arnaud: the only downside is that if we come up with a better way, we still have to support the old rel=describedby link
<sandro> Arnaud: worst case, we need to send around extra describedby links
Arnaud: it's not a big problem
<sandro> PROPOSED: we'll use rel=describedby as in the spec currently, for both metadata on binary resources, and expressiing constraints during server error messages. These are both descriptions and there may be lots of other kinds in the future, too.
<JohnArwe> +0 (don't care/fine either way)
<TallTed> +1
<sandro> +0.9
+0
<roger> +1
<betehess> +0
<SteveS> +1
<MiguelAraCo> +0
<Arnaud> RESOLVED: we'll use rel=describedby as in the spec currently, for both metadata on binary resources, and expressiing constraints during server error messages. These are both descriptions and there may be lots of other kinds in the future, too.
<sandro> http://www.w3.org/TR/powder-dr/#assoc-linking
<JohnArwe> http://www.w3.org/2007/powder/powder-errata
<JohnArwe> within errata, search on: Misalignment of definition of wdrs:describedby cf. @rel describedby
<TallTed> better -- http://www.w3.org/2007/powder/powder-errata#describedby
[people talking about defining describedby or linking to the right definition]
<sandro> Do we keep this: We define the RDF property wdrs:describedby, the meaning of which is identical to the describedby link relationship type defined above so that:
<sandro> ... if we're defining a spec for rel=describedby.
sandro: I'm suggesting we change
anything that would affect implementations, just
editorially
... we can define describedby the way we want it, and still
keep the link header definition from powder
<JohnArwe> The relationship A 'describedby' B asserts that resource B provides a description of resource A.
<JohnArwe> ...that's the normative definition of it based on the content of the errata linked to above
Arnaud: the reference points to the powder spec which has a bad definition
sandro: the textual definition
from Appendix D is fine
... unfortunately iana links to a different part of the
spec
<JohnArwe> http://www.w3.org/2007/05/powder-s.rdf#describedby
<sandro> sandro: Basically, http://www.w3.org/TR/powder-dr/#appD is fine.
<sandro> http://www.w3.org/TR/powder-dr/#assoc-linking
<sandro> http://www.w3.org/TR/powder-dr/#semlink
<JohnArwe> ...that's the link from the erratum to the RDF Schema document
Arnaud: so we are good from an LDP perspective, it's just the references that need to be fixed
<TallTed> http://www.w3.org/2010/08/26-maintenance.html
sandro: can't we have LDP just
repeat the same definition, instead of using the link from iana
to powder
... basically copy the definition from Appendix D into LDP
<sandro> PROPOSED: Copy http://www.w3.org/TR/powder-dr/#appD, more or less, to LDP, so that the link registry can avoid the powder errata situation, pending confirmation from IETF liaison that this is reasonable
<sandro> +1
+1
<SteveS> +0.5
<betehess> +0
<TallTed> +1
<nmihindu> +0
<JohnArwe> +0.5
<Ashok> 1
<Arnaud> RESOLVED: Copy http://www.w3.org/TR/powder-dr/#appD, more or less, to LDP, so that the link registry can avoid the powder errata situation, pending confirmation from IETF liaison that this is reasonable
<sandro> (the "more or less" is meant to cover the fact that the link will of course be different., as will the description of the process.)
<sandro> ACTION: sandro follow up on resolution about moving rel=describedby text [recorded in http://www.w3.org/2014/04/15-ldp-minutes.html#action01]
<trackbot> Created ACTION-138 - Follow up on resolution about moving rel=describedby text [on Sandro Hawke - due 2014-04-22].
Arnaud: let's talk about the LDP
spec now, what do we need to move forward
... what does it mean to go to CR?
... it's an explicit call for feedback
<SteveS> Process stuff http://www.w3.org/2005/10/Process-20051014/tr#transition-reqs
Arnaud: as part of the process we have to define our exit criteria for CR
Ashok: you want to go to CR on
the spec (and only on the spec), no paging spec
... paging is really important, so is patch
Arnaud: at this point the spec is what it is, but as soon as we make progress on paging/patch we can update the spec and/or point to those documents
Ashok: paging is a fundamental
part of our scope
... it is one of the two big questions, so can we go to CR with
only half the work?
Arnaud: we made a decision to
move paging to the side for now
... I agree that is is on the charter and we will dedicate time
to it
timbl: paging is useful but patch is more vital
Arnaud: paging is still on the
table, we're not dropping it
... it would be better to have something (LDP) even without
paging, as opposed to not making it to CR at all due to
paging
... we can delay Accept-Post
... we're waiting on progress from the IETF
... we'll carry both features to CR for now
... CR is open-ended, we don't exit until we meet the
criteria
... going back to the CR discussion now
sandro: the exit criteria is about either having two implementations that pass every test, or every test could be passed by at least two implementations
Arnaud: some parts of the spec are difficult to test (i.e. MUST vs SHOULD)
sandro: those are useful tests but they are not required for CR exit
<nmihindu> related section on non-testable parts in test suite document -> https://dvcs.w3.org/hg/ldpwg/raw-file/tip/Test%20Cases/LDP%20Test%20Cases.html#test-suite-coverage
timbl: test suits should be public, even though W3C does trust the spec implementors
<codyburleson> We are implementing - with goal for Q3. So, we will have a lot of the internals within a month or two.
<nmihindu> Arnaud, every test is passed by at least two implementations seems to be the better criteria
<sandro> sandro: Are your implementations expecting to be feature-complete for LDP?
Arnaud: let's go around the table to see who plans on implementing it
[around 4-5 people]
<sandro> raised hands from: roger, steve, andrei, alexandre, TallTed
<Ashok> ... and Oracle
<sandro> roger: server and client library, focus on direct and indirect containers, written in Scala, not open source
SteveS: a simple reference server, a thin layer to prove the entire spec (in java)
<sandro> SteveS: a number of impls, including a simple reference server (jaxrs + jena), supporting everything in LDP, Open Source (Eclipse)
<nmihindu> nmihindu: we will have one implementation for the ALM iStack project from UPM http://www.centeropenmiddleware.com/news/overviewofthefirstyearofthealmistackproject and a variant of that combined with R2RML http://oeg-dev.dia.fi.upm.es/morph-ldp/. We plan to open source our implementation as soon as we figure out some bureaucratic stuff.
<sandro> SteveS: products at their own pace
<sandro> andrei: open source server, personal data store, in PHP; working on another one in go.
<sandro> andrei: only basic containers.
<sandro> andrei: also client (cimba), uses basic containers
<nmihindu> nmihindu: in ALM iStack, we might not support all the features in the spec thought for the first version.
<sandro> betehess: Scala, supports basic containers
<sandro> SteveS: indirectContainers is planned, but not done
<sandro> sandro: Don't implement it just for CR. Implement it if your users want it.
TallTed: we are working on an implementation (full featured) but we don't have an ETA
<sandro> TallTed: Working on an implementation. I don't have ETA. Probably full features, client and servers. At least virtuoso engine able to act as client and server.
Ashok: we've started working on an implementation
<sandro> Ashok: We might have two. Just starting, probably not ready in the 3-6 month timeframe.
<nmihindu> Apache Marmotta which Sergio et al. are working on.
<SteveS> http://wiki.apache.org/marmotta/LDPImplementationReport/2014-03-11
<sandro> sandro: I think at some point we'll have a much better, elegant thing for what DirectContainer and IndirectContainer do. But I'm okay with us proceeding with including them, since we don't have those elegant things yet.
Arnaud: let's get back to the exit criteria
<sandro> arnaud: I think we're in a fairly healthy situation on implementations
Arnaud: each feature of LDP must
be implemented by at least 2 implementations
... we rely on people making a statement about it, say whether
or not they have implemented it
<sandro> Each Feature and Test has been implemented by at least two independent implementations
<Arnaud> PROPOSED: define exit criteria as: Each Feature and Test has been implementation by at least two independent implementations
<codyburleson> Wouldn't 3 be better than 2, so that there can be a majority on one side of any issue rather than just 1 vs 1?
<sandro> PROPOSED: Define exit criterial: Each feature implemented and each test passed by at least two independent implementations
<codyburleson> OK
<sandro> Arnaud: codyburleson we don't do majority -- if there's a disagreement we work it out, and come to consensus.
<betehess> +1 sounds good
<nmihindu> +1
<codyburleson> +1
+1
<Ashok> +1
<sandro> +1 but of course the details depend on the checklist of fatures and the test suite
<sandro> RESOLVED: Define exit criterial: Each feature implemented and each test passed by at least two independent implementations
Arnaud: let's talk about the BP&G
<codyburleson> Status:
<codyburleson> All BPs in original wiki doc have been added (and words refined).
<codyburleson> TO DO: Update to reflect new revisions in spec; specifically: containe rtypes and code examples
<Ashok> Pl. paste URL
Arnaud: cody, as the editor for the BP&G document, can you please give us an update
codyburleson: now that the spec
has changed, the document needs to be updated to reflect the
changes (e.g. container type)
... at least two things from today also need to be added
<sandro> https://dvcs.w3.org/hg/ldpwg/raw-file/default/ldp-bp/ldp-bp.html
codyburleson: I could update the document to catch up with the spec in the next couple of days, but I think the document also needs a team review
Arnaud: I'd rather ask people to
review the spec when you think you're done
... reviewing the document after every change is not
efficient
... do you need people to review it *now*?
... is there an immediate benefit?
codyburleson: not really, I need
to add today's items
... after this meeting, I could use a few days to update the
spec and present it for review
... I don't know if I have the right words for the changes
right now, so I might need to talk to people
Arnaud: if you're not sure, you
could put some placeholders in the document and then signal
when you're done so we can assign 2 people to review it
... this doc has never been officially published, and we need
to get to that stage since this will be a WG note
<Ashok> q
Arnaud: we need to refer to it in the main spec, so it needs publishing
codyburleson: I can notify the team by 28th to review the doc
Arnaud: on the 21st we'll have a
formal call, so 28th would be good
... we can assign two people to look at it then and then
hopefully publish it
<sandro> sandro; Section 2.3 "Use Relative URIs" obviously needs to be updated with a big EXCEPT ON POST.
Ashok: as we've gone to the spec, we have said that some things need to be clarified and added to the BP&G so I want to be sure they've been caught and they'll be added to the doc
<sandro> sandro: Section 2.3 "Use Relative URIs" obviously needs to be updated with a big EXCEPT ON POST.
codyburleson: I'll track people down and talk to them if I don't understand what's in the minutes
Arnaud: we've volunteered to do
all these deliverables and we need to keep moving, because I
feel that we're not really working on these documents
... once we're done with the LDP spec I'll start hunting you!
(fair warning)
... and haunting too!
<betehess> http://lists.w3.org/Archives/Public/ietf-http-wg/2013OctDec/0625.html
<betehess> [[
<betehess> The most relevant proposals were:
<betehess> A. Opportunistic encryption for http:// URIs without server authentication -- a.k.a. "TLS Relaxed" as per draft-nottingham-http2-encryption.
<betehess> B. Opportunistic encryption for http:// URIs with server authentication -- the same mechanism, but not "relaxed", along with some form of downgrade protection.
<betehess> ]]
Arnaud: in terms of timing, we need to look at the charter and the expiration date and see when and much of an extension we need to request
sandro: "expires June 1st"
[people discussing the W3C technical aspects of charter extension]
[break for 10-15 mins]
[resuming meeting]
Ashok: we're trying to make the Web R/W
[Ashok presents slides]
scribe: databases have stuff that
we haven't got on the Web, such as locking, transactions,
etc.
... you can have data in the databases that has not yet been
computed
... what are we going to do about the http limitations
... some possible solutions are to have clients page through
collections/graph knowing that it may change during this
time
... the client may use ETags to check if the collection has
changed
... client pages through snapshot of collection
... the feedback we got was about snapshots and the fact that
they cost almost nothing
... the database guys are used to this system
... the problem with snapshots is that we don't know when the
snapshots are created and deleted
... the solution is to use locking and transactions instead
Arnaud: we have no guarantee that
as you walk the pages, you have seen all the resources in their
current state
... with http there is no guarantee that a change has not been
produced during this time
... Sandro requires guarantees that resources have not been
missed
... it is a reasonable argument, but a difficult one to
address
Ashok: what happened to Sandro's variable page size proposal?
<sandro> http://lists.w3.org/Archives/Public/public-ldp-wg/2014Mar/0063.html
Arnaud: that proposal is
guaranteeing that you're not going to miss triples, even
through there might be new tripes, but between the time you
started and the time you have finished the traversal, you know
you won't miss triples from that range
... I still this this proposal is on the table
... we got pushed back from Ted
... the question is: can we find something that is better than
what we have now in the spec, which addresses Sandro's
proposal
[debate over snapshots are expensive or not]
<betehess> also cost is not only in size, it's also computing power
[Ashok is defending his take that they are not expensive]
<betehess> scribenick: betehess
Arnaud: if there was a snapshot
feature, of course that'd solve the problem
... not sure we want to do that
... there could be an LDP Snapshot spec
sandro: do we want paging to depend on snapshot?
Arnaud: or we can have paging like it is today, with its flaws
TallTed: it's a best effort
... when we start having snapshot, just advertise it
Arnaud: at WWW last weeek,
somebody presented how to do transactions with 2 phase commit,
in a restful way
... including timeouts
... clients can cancel
... so there are ways to do it
... totally doable
TallTed: we need to study the
database history
... to learn from it
<deiu> scribenick: deiu
<nmihindu> We identified at least 8 different transaction models proposed for REST including TCC which Arnaud mentioned http://ws-rest.org/2014/sites/default/files/wsrest2014_submission_4.pdf
Arnaud: isn't option 2 what we have already
sandro: not really, we need another header
Arnaud: the same comments from 2 also apply to 1
sandro: snapshot is a way to implement lossless paging
TallTed: all are viable options
with different costs and tradeoffs
... we should not force clients to choose one over
another
... the negotiation is really important
<nmihindu> +1 TallTed, it is important if the client can negotiate that based on its needs
Arnaud: I think we should do option 2, to give the client a fair warning
sandro: we just need another header (similar to ETag) but for the main resource that we apply paging to
betehess: what about caching? if you add new headers that are not supported by proxies?
sandro: it shouldn't be a problem if we expose that header in the Vary header
<sandro> OPTION 1: Undetectable Lossy
<sandro> OPTION 2: Detectable Lossy
<sandro> OPTION 3: Lossless Paging (Sandro's)
<sandro> OPTION 4: Use Snapshots
<sandro> OPTION 5: Transactions
<roger> http://ws-rest.org/2014/sites/default/files/wsrest2014_submission_7.pdf
<roger> ?
<nmihindu> The presentation that Arnaud mentioned TCC - http://ws-rest.org/2014/sites/default/files/wsrest2014_submission_7.pdf
<TallTed> thanks, nmihindu!
sandro: my sense is that 2&3
are the only practical options
... people should be able to do paging without snapshots
<sandro> sandro: I want snapshots, but I want paging even on servers that don't support snapshots. So -1 on 4.
TallTed: we need to use common terminology instead of snapshots, so we do not alienate people
sandro: you actually want the state of the resource (of the members) not of the container
TallTed: the best thing to do now
is to document what we have
... option 2 is fine with me
Arnaud: I would like to raise the
bar and say that we should agree to do option 2
... and also to agree to eliminate option 1
<sandro> PROPOSED: At a minimum, on paging, we'll provide a way for clients to detect that a triple fell through the cracks during paging.
<sandro> (ie OPTION 2 as a minumum)
<TallTed> +1
<sandro> +1
+1
<MiguelAraCo> +1
<nmihindu> +1
<roger> +1
<SteveS> +1
<codyburleson> +1
<roger> +q
<sandro> RESOLVED: At a minimum, on paging, we'll provide a way for clients to detect that a triple fell through the cracks during paging.
<TallTed> PROPOSED: Any server claiming paging support must provide a way for clients to know that the resource/collection/whatever being paged has changed during the paging.
<sandro> TallTed, that's the right spirit, but....
roger: if the ETag header is not
there, then the client falls back to option 1
... it's the same as how ETags are used now, clients use it if
it's there
Arnaud: we're starting to converge, so let's see if we can eliminate the transactions
<nmihindu> we would like to have transaction but we are happy to do it outside the LDP spec
Arnaud: the LDP does not _require_ you to do transactions for paging
<sandro> PROPOSED: We're not going to require use of transactions in order to have paging
<SteveS> +1
<JohnArwe> +1
<sandro> +1
+1
<roger> +1
<TallTed> +1
<nmihindu> +0
<Ashok> 1
<sandro> RESOLVED: We're not going to require use of transactions in order to have paging
<sandro> PROPOSED: We're not going to require snapshots in order to have (better-than-undetectably-lossy) paging.
<sandro> PROPOSED: We're not going to require snapshots in order to have paging.
<JohnArwe> +1
+1
<roger> +1
<Ashok> -1
<TallTed> +0.5
<SteveS> +1
<MiguelAraCo> +0
<sandro> sandro: Possible design for snapshots: server can include a Link <> rel=snapshot
Arnaud: TAG doesn't really like
the 209 code
... http2.0 support won't happen soon either
<sandro> JohnArwe: you can use Link with an Context (Anchor) to say this is a snapshot of the PagedResource
<sandro> +1 nice!
<sandro> deiu: Servers should not initiate paging. Sometimes you want the 2G resource and dont know how to do paging.
<sandro> client Prefer: maxPageSize=20m
<TallTed> PROPOSED: An LDP server claiming paging support MAY offer snapshots for paging, but snapshots are not required for paging compliance.
Arnaud: I wonder if we have to specify the 3 options and define mechanisms for each of them
sandro: we can make it a note
Ashok: you can also point to a set of best practices
TallTed: the availability of having that option (3) is key to having paging support
Arnaud: how does the client
figure out which options are available?
... I'm trying to understand how simple/complicated things will
be
sandro: option 2 can be done with
an extra header; the client doesn't need to request
anything
... Link rels can be used for 3 and 4
<TallTed> http://mementoweb.org/
<JohnArwe> http://www.rfc-editor.org/info/rfc7089
<TallTed> just noticed possibly useful... -- http://tools.ietf.org/html/rfc6585 -- "428 Precondition Required"
Arnaud: we should call it a day
<TallTed> complete current HTTP status code list - http://www.iana.org/assignments/http-status-codes/http-status-codes.xhtml
<Arnaud> meeting adjourned
<codyburleson> Thanks!
<codyburleson> G'night.
<Arnaud> bye
<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/for me/for it/ Succeeded: s/Notee/Note/ Succeeded: s/@@/QCRI/ Succeeded: s/one/that one/ Succeeded: s/describedBy/describedby/ Succeeded: s/@@/implementation feedback/ Succeeded: s/to a/relative to a/ Succeeded: s/Add it BP/Add to BP/ Succeeded: s/that's where I think the sparql store protocol does a good job/the sparql protocol does make use of named graphs/ Succeeded: s/TallTed: the spec speaks about a preference to use a syntax supporting named graphs/TallTed: the spec speaks about a preference to use a syntax supporting named graphs when `providing [a] resource and supporting containers in a single response representation.`/ Succeeded: s/graph/a graph/ Succeeded: s/spec/state/ Succeeded: s/describedBy/rel=describedby/ Succeeded: s/defined/define/ Succeeded: s/is/could be/ Succeeded: s/alexandre/alexandre, TallTed/ Succeeded: s/2-3/3-6/ Succeeded: s/been implementation/been implemented/ Succeeded: s/we have happy/we are happy/ Found ScribeNick: Alexandre WARNING: No scribe lines found matching ScribeNick pattern: <Alexandre> ... Found ScribeNick: betehess Found Scribe: Alexandre Found ScribeNick: deiu Found Scribe: Andrei Found ScribeNick: betehess Found ScribeNick: deiu Scribes: Alexandre, Andrei ScribeNicks: Alexandre, betehess, deiu Default Present: +1.617.715.aaaa, nmihindu, codyburleson, MiguelAraCo, ericP Present: +1.617.715.aaaa nmihindu codyburleson MiguelAraCo ericP WARNING: No meeting chair found! You should specify the meeting chair like this: <dbooth> Chair: dbooth Found Date: 15 Apr 2014 Guessing minutes URL: http://www.w3.org/2014/04/15-ldp-minutes.html People with action items: sandro[End of scribe.perl diagnostic output]