Linked Data Platform (LDP) Working Group Teleconference -- 15 Apr 2014

<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

LDP Specification

<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

<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

Null-relative-URI comment

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

<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

<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

describedby

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

<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

<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

<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:

Best Practice

<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]

paging

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

<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

<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

<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

- DRAFT -

Linked Data Platform (LDP) Working Group Teleconference

15 Apr 2014

Attendees

Contents

LDP Specification

Null-relative-URI comment

describedby

Best Practice

paging

Summary of Action Items

Scribe.perl diagnostic output