Linked Data Platform (LDP) Working Group Teleconference -- 12 Sep 2013

<trackbot> Date: 12 September 2013

<Arnaud> hi guys

<Arnaud> we're still setting things up in the room

<Arnaud> we'll be starting shortly

<SteveS> Scribe: SteveS

F2F Agenda Review

Reviewing http://www.w3.org/2012/ldp/wiki/F2F4

Arnaud: Shorter F2F meeting than usual (2 days) and need to prioritize what we need to do
... reviewing last call handling of comments and reaching CR (or another LC)

…pretty sure we'll need to go to another last call based on how we handle TBL's comments

<rgarcia> Now the sound is better

Arnaud: primarily will be working on TBLs feedback/issues the next couple of days
... Only have 4 deliverables in the charter itself and others not

<rgarcia> I will be during the mornings, so I prefer that we talk about the test suite then

not sure there is much to cover with UCR but will defer until Steve Battle is around

<rgarcia> Today or tomorrow (better tomorrow)

davidwood: has conflict 1-2:30 today

sandro: has conflict 11-12 today

Arnaud: looking to cover patch at some point but would like to get Andy in for that, perhaps only cover for a fixed time

Specification last call comments

Arnaud: screwing with agenda

See tracker https://www.w3.org/2006/02/lc-comments-tracker/55082/ldp/

Arnaud: put Tim's comments into this, including others

proposing that when we want to address a handle an issue from comment, we open an issue in tracker to record WG resolution

<bblfish> hi

JohnArwe: it is possible that the WG addresses a comment that the commenter doesn't agree with

Arnaud: yes but we work to get them to agree with resolution is the preferred way of handling, but not always possible

(discussion back and forth on handling or not handling comments, formal objections, w3c process)

JohnArwe: Do I propose the proposal to the WG to get their blessing before reaching out to commenter?

Arnaud: yes, we should get WG consensus on it before we distribute

Want to make sure we don't provide direct feedback to commenters on resolutions unless we are sure we have WG consensus

<Arnaud> https://www.w3.org/2006/02/lc-comments-tracker/55082/ldp/2812

Mark Baker's comment LC-2812

JohnArwe: Mark pokes on the redefinition of DELETE in our spec

sandro: not sure why HTTP didn't require a true DELETE of the resource

davidwood: done in a way in that it is hard/impossible to enforce a true delete

<davidwood> bblfish: We should ask Mark what danger he sees if we redefine HTTP DELETE

bblfish: we should go back and ask what exactly he thinks will break

JohnArwe: has interaction with mark and he thinks LDP client should be same as a generic HTTP client

bblfish: wonders if he has any issue with container specific behavior

Ashok: do we agree that clients are generic?

Arnaud: seems to be a common question we keep hearing

<bblfish> yes, so for example an LDPC has a certain way of behaving that is defined by an LDPC: I wonder what mark baker makes of this.

Arnaud: hard to imagine how a client that wouldn't see a switch to know it is a LDP server it is working with and need to go done that code path

davidwood: we have the liberty to expand on what is in HTTP and need specialized LDP interaction

bblfish: an LDP client should work with any LDP server, without having to learn from web site admin…is why TBL is saying this

<davidwood> bblfish, yes, we agree on that

<roger> +q

TallTed: how does a generic client with a specific server? curl is a sample of this, the end user has the logic to interact with the server

sandro: is curl an LDP client??

JohnArwe: curl is http client

roger: thinks that we can improve over time how generic an LDP client can be, having some limitations in initial spec

bblfish: agrees that curl is example of generic HTTP client, a generic LDP clients knows the specifics of LDPRs and LDPCs + interactions

roger: not quite enough as we need new extension for which types of resources

bblfish: recaps discussion from madrid and his proposal on expressing which types of things that can be put into a container

Arnaud: looking back to Mark's specific comment

<bblfish> Arnaud: can you make a recap of the discussion on the talks that you were at?

<roger> I think we need to be explicit about these hypermedia related 'gaps' in the state of LDP alone - that we recognise these gaps, but we are looking to fill them !!

Arnaud: looking back on Ted's point, wondering what breaks on generic HTTP clients (like curl) with DELETE

sandro: doesn't see anything in spec that would make curl a non-conformant LDP client, i.e. wouldn't break anything

…requires the human to respect some of the LDP rules

JohnArwe: some of the other points Mark makes is some of best practices

sandro: sees conformance as if a product advertises, but doesn't do it…I could get my money back

…I think these pass that test (are conformance criteria) and don't agree with Mark here

JohnArwe: Mark doesn't want a specialized LDP client (recapping) and also that an HTTP client (not saying generic) can work with an LDP (any) server

sandro: thinks that we can decide we can restrict an LDP server

ericP: POSTing to an HTTP server is anything in HTTP spec, where in LDP we refine/restrict it to be create.

sandro: is saying his bottle of water may be a compliant http server

TallTed: sees that an HTTP client should work with an LDP server using it as HTTP server, but if it uses LDP capability it must conform to LDP spec

<sandro> so any http server is an ldp server -- it just might not happen to have any LDPRs or LDPCs.

bblfish: LDP server can be an HTTP server, just need that the LDP-resources behave according to the LDP spec…leave any resource on the web to remain to HTTP to define

nmihindu: agrees with sandro in that the behavior server but more on the specific web resource

<davidwood> +1 to nmihindu. Many of the MUSTs relate to content.

Ashok: how can I tell resource is an LDPR or just a plain thing?

<TallTed> TallTed: LDP can roughly be defined as extensions/restrictions on HTTP. *within* LDP functionality space, LDP client/server must xyz, but when LDP functionality/LDPC/LDPR are not being addressed, an LDP client/server is just an HTTP client/server

<TallTed> TallTed: any LDP server is an HTTP server; any HTTP server is not necessarily an LDP server. any LDP client is an HTTP client; any HTTP client is not necessarily an LDP client.

<TallTed> TallTed: (human + curl) can be LDP client. curl alone is an HTTP client.

<sandro> you do an HTTP interaction with it.

SteveS: you can inspect the Link header with type ldp:Resource

as a response to any request, OPTIONS is the lightest

<Zakim> davidwood, you wanted to discuss generic HTTP clients operating on LDP servers

davidwood: looked through spec of MUSTs in what would break if I used vanilla HTTP interactions, don't see anything would break. Suggest turning to Mark to point out specifically what will break

<nmihindu> TallTed, (script + curl) could be an LDP client too, isn't it ?

<TallTed> nmihindu - yes, human effectively delegates to script

<sandro> I was talking about: 4.5.5 An LDPR client MUST preserve all triples retrieved using HTTP GET that it doesn’t change whether it understands the predicates or not, when its intent is to perform an update using HTTP PUT. The use of HTTP PATCH instead of HTTP PUT for update avoids this burden for clients [RFC5789].

davidwood: says that we can't prevent authenticated client from garbage in from garbage out, rude for clients to through out stuff it doesn't understand

bblfish: believes that this could be an access control, allowing then only additive and can preserve

TallTed: can be that someone with more permissions to be able to still remove it

sandro: good to define well-defined client behavior in that a client shouldn't throw stuff out it

<bblfish> The discussion seems to be about: what can a generic client do that would be bad and should the spec be talking about it. Not sure why this is the discussion point.

miguel: is there a case where we require a genetic HTTP client to an LDP server on LDP resources?

TallTed: not sure this is any

Arnaud: what do we need to get back with Mark

JohnArwe: than an HTTP client can interact with an LDP server, all behaviors with constraints on LDPRs and LDPRs still are within bounds of HTTP

<sandro> An LDP Server is an HTTP Server which offers one or more LDPC or LDPR.

<bblfish> I think we agree here. +1

<davidwood> +1

<bblfish> distinguish LDP Resources, LDP Clients and HTTP Clients . LDP Cleints are subsets of HTTP Clients. LDP resources are a subset of HTTP resources

TallTed: thinks we make it hard for server implementers as the have to go through the spec and clearly list out what a server needs to do

<bblfish> I'd say LDP Server =def a Server that servers LDPR resource

Arnaud: believe that we has it by server criteria, and needed some change

<sandro> Maybe "An 'ldp client' is an HTTP client that is interacting with an LDPR or LDPC."

<Zakim> sandro, you wanted to say that maybe there is no LDP Client -- instead these are requirements/suggestions for all clients interacting with LDPRs and LDPCs.

JohnArwe: we made it clear which criteria are for clients vs server by preceding each req

<nmihindu> +1 to sandro. May be a client who is aware of LDP restrictions that is interacting with an LDPR or LDPC.

sandro: changing opinion that there isn't an LDP client, in that there is rules for HTTP clients that interact with LDP resources/servers.

TallTed: sees that GET/PUT and the separate client activity on the data and the rest is the protocol

sandro: see it as an action, such as patch, where you the entirety to complete that action is to get, only mod what you want, then put

bblfish: question of what is an LDP client?

<sandro> Proposed: an "LDP Client" is an HTTP Client, interacting with an LDPR and LDPC, following the restriction in this spec.

SteveS: optimization, an LDPC is an LDPR

TallTed: curl is generic HTTP client that can be used to interact with WebDav server. It is the end user who would not be well-behaved in webdav interaction

<Zakim> davidwood, you wanted to discuss the lack of transactionality

<sandro> thanks steve.

davidwood: http is based on stateless interaction, you can't guarantee that another client modified a behind another one

sandro: you can use etags and if-modified header to prevent concurrent mods

<davidwood> However, an LDP server can use ETag matching to issue a 405 in the event of a conflict.

<sandro> So.... We reply to Mark, saying a conforming ldp client is an http client that is following the behavior specified in this spec (when accessing an ldpr); and a conforming ldp server is an http server that is following the bheavior specified in this spec (when serving an ldpr).

Arnaud: not hearing any disagreement within the group on this approach, so John can draft a response and get group feedback
... not hearing a normative change to a spec

JohnArwe: agree, perhaps some editorial

<bblfish> I think that is not the definition we were using of a Generic HTTP client. A browser is a specialised HTTP Client. Curl is a generic HTTP Client.

<bblfish> ( we have to be careful to distinguish those )

<bblfish> ( A browser is a generic HTML+http client )

<TallTed> +1 bblfish

<sandro> PROPOSAL: We reply to Mark Baker, saying a conforming ldp client is an http client that is following the behavior specified in this spec (when accessing an ldpr); and a conforming ldp server is an http server that is following the bheavior specified in this spec (when serving an ldpr).

<sandro> +1

<nmihindu> +1

<nmihindu> +1 for mesteban

<TallTed> +1

<rgarcia> +1

<roger> +! and we say that we are working on the gap (hateoas shaped)

<ericP> +1

<davidwood> +1

+1 for JohnArwe

<roger> +!

<roger> +1

<sandro> RESOLVED: We reply to Mark Baker, saying a conforming ldp client is an http client that is following the behavior specified in this spec (when accessing an ldpr); and a conforming ldp server is an http server that is following the bheavior specified in this spec (when serving an ldpr).

<davidwood> ☃

<davidwood> Sorry, that should be +☃

<bblfish> 🍹

<bblfish> 🍹?

<bblfish> 👍

<davidwood> Back from break

<davidwood> scribenick: davidwood

Arnaud: Reviewing outstanding comments, issues and features at risk

…There is quite a bit of work to do.

<sandro> (watching IRC from 30m away, sitting in another meeting)

…The issue regarding inlined resources came up.

<roger> https://www.w3.org/2006/02/lc-comments-tracker/55082/ldp/2837

…inlining is currently at-risk: https://dvcs.w3.org/hg/ldpwg/raw-file/default/ldp.html#member-inlining-returning-all-of-a-container-page-s-members-in-a-response

…propose to remove it from the spec.

Ashok: Is inlining a requirement? If so, it should be fixed.

The spec currently says, "One of the most commonly cited scenarios for resource inlining is to save clients enumerating a container of m members from having to perform m+1 HTTP requests". How would that common use case be addressed?

Arnaud: It would not be addressed under this proposal.

John, Eric: Addressing this requirement out of band is not addressing it in an interoperable way.

SteveS: Clients need to know the boundaries of what they can GET or query. We could drop it, but try to put it back in later.

Ashok: Maybe just leave it as a feature at risk.

Arnaud: I don't think we have time to fix it.

<bblfish> the problem is that this requires TriG and N3 for it to work.

<SteveS> or multi-part/mixed

TriG is on the Rec track.

bblfish: We need TriG, and the spec might be ready. We could do it later.

<SteveS> not sure we need TriG, could split the HTTP responses in a multi-part/mixed response

Arnaud: We would need to evaluate multiple proposals, and don't have time.

<bblfish> ah yes and there is SPEEDY too

SPDY proposal at IETF: https://tools.ietf.org/html/draft-mbelshe-httpbis-spdy-00

<Arnaud> PROPOSAL: drop inlining from the spec, put it on the wish list for LDPnext

<rgarcia> +1

<nmihindu> +1

<Ashok> 0

<roger> +1

<nmihindu> +1 for mesteban

<bblfish> +1

<TallTed> +1

Arnaud: A problem is that you don't know the boundaries of a container. You might get data back that transcends a boundary you presume.

John and SteveS discuss the boundary problem.

<bblfish> good axplanation from arnaud: it's like you ask for a driectory and you don't just get back the directory, but you get back the directory and the files but you don't know where one file starts and the other ends.

<SteveS> +1

<ericP> +1

<Arnaud> RESOLVED: drop inlining from the spec, put it on the wish list for LDPnext

RESOLUTION: drop inlining from the spec, put it on the wish list for LDPnext

ISSUE: Should inlining be dropped from the LDP spec due to time and complexity to fix?

<trackbot> Error creating an ISSUE: an internal error occurred. Please mail <sysreq@w3.org> with details about what happened.

<TallTed> issue-81?

<trackbot> issue-81 -- Confusing membership* predicate names and other possible improvements -- raised

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

ISSUE-83?

<trackbot> ISSUE-83 -- Should inlining be dropped from the LDP spec due to time and complexity to fix? -- raised

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

CLOSE ISSUE-83

<trackbot> Closed ISSUE-83.

ISSUE-81

<trackbot> ISSUE-81 -- Confusing membership* predicate names and other possible improvements -- raised

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

John: Readers are confused by the membership predicate names.

Arnaud: Open ISSUE-81?

OPEN ISSUE-81

<TallTed> +1 open it

<Arnaud> PROPOSAL: Open ISSUE-81

<nmihindu> +1

<rgarcia> +1

<TallTed> +81

<Ashok> +1

<roger> +1

<nmihindu> +1 for mesteban

<SteveS> +1

REOPEN ISSUE-81

<trackbot> Re-opened ISSUE-81.

<Arnaud> RESOLVED: Open ISSUE-81

SteveS: Discussing how membership is expressed in an LDPC

…ldp:membershipObject is confusing compared with other membership* predicates.

<roger> +q

…ldp:membershipPredicate and ldp:membershipPredicateInverse also confusing. ldp:membershipPredicateInverse turns membershipPredicateSubject into an Object...

John: ldp:membershipPredicateInverse is poorly named - cannot explain it well to people.

<Arnaud> http://www.w3.org/2012/ldp/track/issues/81

SteveS: Walking through proposals in ISSUE-81

TallTed: The old way allowed a client to know that a container is either in the subject or object position - not both or either.

…This proposal will cause more confusion.

…By referring to a predicate in an object position, it makes it hard to read. Not supposed to force readers to be RDF experts.

John: The inverse case is more common.

SteveS: slightly - maybe 60/40

Arnaud: Do not want to reopen an issue just for terminology.

bblfish: Propose to have a member relation that points to a blank node with spo properties.

<TallTed> maybe s/ldp:membershipPredicateInverse/{ ldp:containmentPredicate | ldp:containershipPredicate }/

<bblfish> ldp:consequence [ lpd:subject ... ; ldp:object ...; ldp:predicate ]

John: SteveS's proposal does address part of what bblfish wants.

Arnaud: We only need a different syntax to use for the design we already have.

<roger> +q

EricP: What pattern will a user look to in order to find out how to traverse an LDPC?

<ericP> Arnaud: and what pattern will the server invoke when a client POSTs a new resource

<roger> i am just saying that by grouping the three membership* predicates (and potentially giving that group a URI), then it makes predicates on a LDPC look simpler.

<bblfish> so I was thinking the above could be <> ldp:consequence <some#x> . And then in <some> could have <#x> ldp:subject ...; ldp:oject ...; ldp:predicate ... ] .

<bblfish> so I was thinking the above could be <> ldp:consequence <some#x> . And then in <some> could have <#x> ldp:subject s; ldp:oject o ; ldp:predicate p ] .

<bblfish> and then <#x> is something like a rule that can be formed by replacing s, o and p in it. What that rule would be is an interesting question. Perhaps a SPARQL INSERT into <s> { s p o } // it's not that but that's as much as I can get to

<ericP> davidwood: in callimacus, we run into the issues where we've left cardinalities implicit and we end up seeing e.g. n HTTP <title/>s

davidwood: Encourage the editors to define any implicit cardinalities.
... Propose to change the terms to use meaningful names instead of Subject, Predicate, Object.

…e.g. ldp:consistentResourceURI

Discussion ensues

<TallTed> ldp:membershipCollectiveName ldp:membershipRelationshipName ldb:membershipMemberName

<TallTed> or

<TallTed> ldp:membershipAggregateeName ldp:membershipAggregateRelationship ldb:membershipAggregateElement

<TallTed> or better

<TallTed> ldp:membershipAggregateeName ldp:membershipAggregateRelation ldb:membershipAggregateElement

Arnaud: We will break on this for now to let people think about naming.

…and maybe even a change in design.

Breaking 30 minutes for lunch.

<sandro> scribe: sandro

LC-2815 (Ashok)

Ashok, I think we resolved this one already.

Ashok, We didn't address containers within containers -- how does ordering work?

Ashok: can you have a container of containers and other resources?

SteveS: Yes. Ordering is in the data. An LDPC is an LDPR.
... You could order on the non-member properties

Ashok: If you want to order containers within a container, you can only use the non-membership properties?

SteveS: Would you want to order the member resources of the subcontainer within the top-level container?
... I don't know why why anyone WOULD order the membership URIs, but I don't see any reason to forbid it.

Arnaud: In my app, I have some ...... the spec allows it

Ashok: It's not spelled out. I'd like a line saying if there are containers within containers, you can order the contained containers.

ted: It's just like ordering anything else within a container. Why do we have to be specific.

Ashok: It might confuse people.

SteveS: IBM usernames example
... #steve, #john, ...

cody: Isn't it likely the containers wont have the same properties?

SteveS: Yes.

Arnaud: Can we close this by having the editors add something to the spec saying yes you can order the containers within a container.
... in main spec, not best practice.

cody: But aren't the properties going to be different?

SteveS: You don't ask for sorting -- the server just tells you how it's sorting.

Arnaud: Ordered by that property, but several resources don't have that property.

sandro: Servers can make sure all the contained elements have the sort property you want

cody: but aren't containers likely to have different properties?

<Arnaud> PROPOSED: dispose of second part of LC-2815 by clarifying the intent in the spec: LDPCs are LDPRs and sorted the same way

JohnArwe: The server picks the sorting, and just tells the client what it is.

<SteveS> +1

should be LC-2815

<Ashok> +1

<TallTed> +1

<TallTed> s/LC-285/LC-2815

<nmihindu> +1

<nmihindu> +1 for mesteban

<Arnaud> RESOLVED: dispose of second part of LC-2815 by clarifying the intent in the spec: LDPCs are LDPRs and sorted the same way

LC-2816

Ashok: close this - it was an error on my part

<SteveS> http://lists.w3.org/Archives/Public/public-ldp-comments/2013Aug/0005.html

LC-2813

https://www.w3.org/2006/02/lc-comments-tracker/55082/ldp/2813

Ashok: From our product guys: What do we do about auth and acls?

Arnaud: In the presentations I give, I include a slide "What We Are Not Doing". These are obvious questions. Let's provide this pro-actively.

roger: This is in line with my comment this morning. Pre-emptively, why are you not Type-4 Restful.

<SteveS> Enough to point to HTTP 11. Access Authentication http://www.w3.org/Protocols/rfc2616/rfc2616-sec11.html#sec11

JohnArwe: Just point to http

Ashok: They ask "should I use oauth", etc

Arnaud: Let's have a non-normative security section.

Ashok: Do we need a Security Considerations?

sandro: No, that's IETF (eg Media Types) not W3C

cody: So will we say something like Ashok suggests?

<Arnaud> PROPOSED: dispose of LC-2813 by adding a non-normative section on security setting the expectation right, pointing out that this isn't covered in LDP

<SteveS> +1

<TallTed> +1

<Ashok> +1

<nmihindu> +1

<nmihindu> +1 for mesteban

<bblfish> +1

<roger> +1

<Arnaud> RESOLVED: dispose of LC-2813 by adding a non-normative section on security setting the expectation right, pointing out that this isn't covered in LDP

Primer

Arnaud: Roger, Nandana?

<roger> https://dvcs.w3.org/hg/ldpwg/raw-file/tip/ldp-primer/ldp-primer.html

nmihindu: We have the examples. Most of the content is done

roger: It's a primer for understanding the spec, rather than for supporting massive use of LDP. It's got a lot of detail about the spec. It's a lot more than just Hello World, explained.
... There's still a gap. There's still a need for the 2-minute intro to LDP. What it is, and why to use it.

nmihindu: Let's do like with the use cases. WG review...

Arnaud: We need to get it to the point where the editors call it done.

roger: I meant to get my part done by the F2F2. But we're way more than 50%

john: Is it done enough to have people review it?

sandro: The process is (WD)* (WGNote)+

nmihindu: If we go for a public comment draft. It would be nice to have this with LC2.

john: Point to it as informative reference from LC2

sandro: Yeah - so we publish on the same day.

Arnaud: So, when is it really going to be ready for WG review, for FPWD?

nmihindu: Henry and Ashok agreed to review it.

bblfish: the WebID WG was just about to publish three WebID specs....

sandro: There is no WebID WG

Arnaud: Does that relate to the primer?

<TallTed> it's the WebID CG ... which is generally orthogonal, until we get to access control and the like

bblfish: Just a bit of advertising here.

sandro: WebID can ask LDPWG to review its spec.

<nmihindu> bblfish, we will talk about security in the primer referring to the access control note

Arnaud: Sure, but let's talk about that later, not under Primer.

<bblfish> yes, I understand. It's just that there is one year to go https://dvcs.w3.org/hg/WebID/raw-file/tip/spec/index.html

<bblfish> and if you guys are interested to have this let me know.

roger: We'll be done by the end of September.
... 5-10 minutes feedback NOW would be excellent.

sandro: Why not make the Intro be the Hello World "primer"?

<bblfish> yes, the primer looks good

sandro: the elevator pitch for LDP

roger: Reasonable idea.

<bblfish> :-) Ah ok. I was going to say the same about it being Replace

roger: My talk at RDFVal was a lot like the hello world
... The pictures start to get not very useful, eg pagination.

<bblfish> +q

sandro: URLs should either be example.org or someone personally committed to maintaining them or hosted on W3C

eric: like in the test harness.

TimBL's comments

Arnaud: I tried to split Tim's comments up by topic.

<bblfish> Are you pointing at something?

<bblfish> a URL?

https://www.w3.org/2006/02/lc-comments-tracker/55082/ldp/?status=open&

subtopic: Vanilla

https://www.w3.org/2006/02/lc-comments-tracker/55082/ldp/2833

Arnaud: This is what we talked to Tim on the phone about
... Tim comes from a different point of view. I want a generic server that would never drop my triples.
... We talked about important use case of domain-specific servers. OSLC demo on bugzilla, turning it into LDP server.
... If the hard requirement is every server has to manage any kind of server, then things like that would never be LDP servers.
... He understood where we were coming from.
... He said maybe two levels of compliance

SteveS: This bugzilla facada requires no storage.
... You COULD put a triple store into the facade, but that adds a lot of implementation burden.

Ashok: Difficulty is that the spec does not speak of app-specific servers and generic ones.
... Let's talk about it early in the spec. "You can do both of these things..... "

john: A lot of the SHOULDS become MUSTS

SteveS: PUT "may" ...

john: The adulteration stuff wouldn't be allowed

SteveS: How would you detect if it's a chocolate or vanilla server

bblfish: We need a way for a client to tell when there are restrictions or not.
... Maybe a report on the Validation Workshop
... I still believe you can come up with one relation that gives you a restriction. Because RDF is a restriction of classes of things. Relation from LDPC ....
... we don't need to wait for RDF Validation to be done.
... just define that relation

4.2.10 LDPR servers MUST advertise their LDP support by exposing a HTTP Link header with a target URI of http://www.w3.org/ns/ldp/Resource

bblfish: Maybe the restriction is a ... something

<roger> +q

<TallTed> sandro: seems like a simple solution is to build off current restriction, every LDPR is identified as such by type header

<TallTed> ... add generic_LDPR and restricted_LDPR subclasses

SteveS: What are all the normative statements that would be different?

<bblfish> I was looking at the issue of a POST. In the case of an LDPC you could create a relation that says you can only POST a subset of all possible documents to that container. There remains the question of restrictions on PUT

SteveS: Eg Tim requires Put-Creates, while I forbid Put-Creates.

john: What are all the ways the client interaction model is different.

roger: I don't see it as two different types. If there's no guidance, you can put whatever you want. ither the server says nothing and can accept everything... or it gives you some constraints.

sandro: Tim wants something more defined now.

roger: I'd think what we have now would be prefect for Tim

sandro: But he says it's not.

Arnaud: 4.2.10 link header, type ldp:Resource

<bblfish> yes, create a subclass of ldp:Resource

Arnaud: What if I don't know the ldp:Resource subclass?

sandro: either client does subclass inference, OR the server enumerates all the classes in different Link type= headers

roger: the thing advertises what it neads, to be involved

john: Just because I feed a container RDF does not mean I get LDP

Arnaud: Tim says "As long as I can figure out if this is my kind of server, then I'm fine".

Ashok: When you store these things, in my database or triples. How do I store LDPRs differeent from other resources.

sandro: I think you store metadata on most stuff you pull from the web

Ashok: okay

<bblfish> To take the PUT case: an ldp that is constrained say to allow only specific types of bugzilla bugs would be an as section 4.2.10 says would advertise in the header that the resource is Link: <http://bugzilla.org/ont/Bug>; rel=type

bblfish: Instead of resources advertise themselves as LDPR, advertise theselves as type "Bug" or whatever.
... then that Bug URLs will at some point have some kind of description of what the restriction is.

+1 (except also with server doing the inference)

<Zakim> sandro, you wanted to talk about Steve's Create issue

<roger> +q

PROPOSED: We'll add a subclass of LDPR for Tim's use cases, and say that servers offering such an LDPR must add link header, rel=type, ldp:VanillaServer (or whatever the class is called)

roger: Henry's proposal doesn't work for me, I need parameterized classes or something
... At some point I have a bug tracker for "ComplexBug" which needs more details
... Second reason -- I think LDP should work without typed resources.

<roger> nothing against typed resource too ... :)

<roger> I just don't they need to be mandatory

Arnaud: We could invent LDP:UnconstraintedResource

sandro: But Put-to-Create isn't really on a resource. It's on a URI space? Or maybe it's on an LDPC.

bblfish: You could have a constraint relation.
... And for now write out the constrains in English.

sandro: WHat problem is that solving?

bblfish: If something has a constraint and you can't understand the constraint, then you should know that you can't do certain things with it.

<roger> it is leaving the space open to put in the outcome of rdfval (possilbly), but, also to put in some kind of human documenation ...

<roger> and the human documentation will probably arrive before the rdfval output

bblfish: I want both kinds of clients without having to wait for the WG to define everything.

<roger> +q

bblfish: The Vanilla thing is too gross. It's not solving the problem, just getting the spec through.

Arnaud: Maybe in the future we can do something more sophisticated.

<roger> for reference, the priority for the rdfval workshop were prioritized: 1 declarative defintion of the structure of a graph for validation and description 2 extensible to address specialized use cases 3 there will be a mechanism to associate descriptions with data

<roger> ... and Henry seems to be asking for number 3 i think

<roger> if no.3 doesn't exist, then it's vanillia

<roger> i.e. if the property don't exist

(scribe gives up for now)

<roger> +q

<JohnArwe> middle ground? Link: rel=constraint, href=ldp:Unconstrained ...the only one LDP defines (Tim's set), but in the end it's open.

sandro: either constraints or the classes of things which meet that constraint. isomorphic framings.

<TallTed> +1 JohnArwe

JohnArwe: We peel off the class of servers we need to address for Tim. The others we leave to be addressed at some point.

<TallTed> http://www.iana.org/assignments/link-relations/link-relations.xhtml

<JohnArwe> ...seems completely compatible with henry's points

cody: can we just use RDFS?

sandro: Alas, RDFS and OWL have different semantics. See Clark & Parsia work/products using altered semantics for OWL to use it for validation.

<bblfish> -1

<bblfish> -1 on the simple Constrained relation

<JohnArwe> how is that different from what you were positing henry?

<TallTed> rel=lrdd --> "Refers to further information about the link's context, expressed as a LRDD ("Link-based Resource Descriptor Document") resource. See [RFC6415] for information about processing this relation type in host-meta documents. When used elsewhere, it refers to additional links and other metadata. Multiple instances indicate additional LRDD resources. LRDD resources MUST have an "application/xrd+xml" representation, and MAY

<TallTed> have others."

<bblfish> I am for a Link: <http://mozilla.org/bugs/ont#bug>; rel=constraint

<TallTed> see http://tools.ietf.org/html/rfc6415

<JohnArwe> So you want the absence of the constraint header to imply vanilla/unconstrained?

<JohnArwe> ...vs simply that you're dealing with an http resource

<TallTed> downside is requirement that LRDD resources must be available as XML.

sandro: graph shape constraints are quite different from protocol action constraints.

<bblfish> ( ie rel=constraint ) And I am ok that this ends up the same as type statement, since a constraint creates a type

sandro: A resource that handles Delete a particular way is clearly a particular class of resource.
... so let's use the classificaiton machiniery we have.

Arnaud: Maybe we jumped ahead to far. Let's go back to Tim's comment.
... Tim wanted MUSTS where we had SHOULDS, because of all sorts of constraints that stop a server from behaving a particular way, eg Read-Only Servers!

<JohnArwe> maybe I'm dense, but I still feel like Henry and I violently agreeing henry.

<bblfish> yes, agree there are different types of constraints: Data contraints, HTTP contstraints, consequences

sandro: Some constraints are good for the client -- agreement to do nice things for client -- and some are not -- agreement to do nice things for OTHER people.
... Maybe go through the differences from Tims

<bblfish> agree: I'd think the HTTP level should be as close together as possible

<bblfish> yes, there is out of band contract which is the big problem, and there is efficiency is important.

arnaud: I think part of the problem is Tim wants some pressure for folks to implement all the things his clients want.

<JohnArwe> Here's the wiki table Sandro: http://www.w3.org/2012/ldp/wiki/ISSUE-32

<bblfish> Tim also asked us to look at the MUSTs for the client and write those up.

<ericP> TallTed: we can identify a potentially inefficient contract that permits a client without an advanced contract to learn about a server

<TallTed> SteveS: compliance statements are unclear -- LDPR Server, LDPC Server, LDP Server -- conformance testing seems to start from profile statement

<Arnaud> scribe: TallTed

arnaud: current examples include LDPR, LDPC; we're talking about adding constrained; question about writeable

<JohnArwe> @sandro: looking at the issue 32 wiki page and the "create constraints" case, no row for 5.4.9 despite that being an old MAY ... so I didn't count that as an "affordance"

ericP: generic, then containers, then resources... behavior we have for posting to container to create resources is not expected of generic client?
... intend a PUTtable (PATCHable) container? what are all the graph shapes you might get as result?
... may need to constrain containers to have same interactions whether backed by triple store or otherwise...

<bblfish> I agree

<bblfish> yes, I agree that there are LDPC and LDPR that are constrained and so for constrained Resources we need to sepcify the constraint

bblfish: the need is to specify constraints applying on the server side, such that the client can understand them

<bblfish> yes

<davidwood> "LDP servers capable of storing arbitrary data" vs. "LDP servers capable of storing only pre-specified data elements"

<bblfish> which one?

Arnaud: timbl gave several hints about what might work, which we should explore
... setting multiple levels of compliance is easier than handling all the different types of constraints
... he also said something like, a silent failure is terrifying. this is true, and we have several points with silent failure (or success).
... the struggle comes down to, we're not telling the client whether something failed, and if it *did* fail, how/why

<roger> either the client calls the shots, or the server does.

<roger> if the client calls the shots, the server needs to be ready for anything (i.e. vanilla)

ericP: during the RDF Validation workshop, there was a big debate about whether you can specify that a server only accepts a subset of triples

<roger> if the server calls the shots, the client does what it is told.

ericP: if a server throws away some of your triples, should you get a 2xx or 4xx result?

davidwood: it's worth spending time on the general-purpose use cases, since this all started from a fairly specific-case analysis
... writing a client, I would love to know that working against LDP Server A, I get different results than against LDP Server B, without recoding...

(20 minute break)

(convo resumes)

<bblfish> hi

<bblfish> yes, I am back.

<bblfish> we can't solve all the problems

rel=type type=ldpServer implies unconstrained;

+ rel=type type=URI dereference leads to constraint definition

bblfish: constraints on http methods seem different from constraints on content
... one is on the type of speech actions, the other is on the type (or specifics) of content

<sandro> "content constraints" and "behavior constraints"

sandro: validation workshop was all about content constraints; we know we're not solving that here

<bblfish> we can't solve the content constraints but we can provide the hook.

davidwood: early spec version said that LDP servers would only support a limited vocabulary
... we could solve content constraints in a limited way, by allowing server to advertise URI to RDF graph specifying that server's supported vocabularies, data types, predicates, etc.
... client could detect that, and know what it could (not) do on that basis
... could have a sample/standard/basic version of this in w3 space, with ability for server-specific local

Arnaud: the "silent" aspect isn't addressed there... we need to start opening a set of issues on these points
... what exactly are we missing? "content constraints" won't be solved, but we need to somehow communicate to the client whether there *is* a set of such constraints
... do we need to advertise "I'm a vanilla server"? does silence somewhere imply that? does silence imply something else?

roger: maybe we should define a predicate that targets the graph constraints document. if it's there, constrained. if not, vanilla/unconstrained.

<bblfish> I am +1 with haiving a relation with domain ldp:Resource and range a subset of foaf:Document .

Arnaud: could be within the content, could be in the header, best to be in both

<bblfish> yes, the link header is rdf

SteveS: rel=describedby could be the one to use

sandro: likes roger's idea of the constraint spec through a header URI

<roger> +q

Ashok: what happens for violations?

sandro: protocol question. could be silent failure, could be error, etc.

Arnaud: need to do something about transparency of partial success/failure, etc.

<davidwood> Ashok, davidwood not happy with silent failures

sandro: if you're a shape-constraining server, you have to validate immediately, and provide results

Ashok: I've heard 3 ideas -- (1) application specific; (2) code says partial storage, partial drop, or delete not done; (3) validation
... is this enough?

<JohnArwe> I do find I'm reacting badly to the notion that absence means unconstrained (vs having no knowledge of constraints), although I have trouble articulating exactly why.

roger: in terms of constraining, have to constrain content if you want to PUT to it, different constraints apply to POST

<sandro> +1 roger ldpc needs a shape for itself and a shape for things that are POSTed to it.

<bblfish> The point is not to do the constraint language here, other than allow an rdfs:comment on the linked to resource that describes in human language what the constraint is.

roger: describedby is good for PUT and POST, but not for GET. accepts might be viable

<bblfish> Agree that we need different relation for an LDPC what needs to be POSTed

sandro: LDPC needs 2 shapes -- one for PUT, another for POST -- one for exists, one for doesn't exist

Arnaud: need to communicate that there are no constraints

sandro: absence of any constraints means it's a vanilla graph
... one predicate is graph restraints for LDPR, another predicate is member constraints for LDPC

Arnaud: what does the proposal look like? I am a client, doing a GET on resource... how do I know I'm dealing with an LDP Server? that the resource is LDPR, LDPC, etc?

<bblfish> it's a Link header

<bblfish> Arnaud it's a Link header of rel = somethypetobedecidedlater

sandro: if the server wants to limit the shape of LDPR content, it will have a Link header to that effect. if if wants to limit shape of LDPC submission, it has a Link header to that effect.

<bblfish> seems good to me

sandro: objection might come from Bugzilla-facade (and similar) space, who'd have to include an extra header

<sandro> PROPOSED: When a server answers a GET or HEAD on an LDPR for which the RDF graph is somehow constrained MUST include a Link header giving a URL for the given constraint. We wont actually specify at this time how those constraints are specified. Natural language is okay for now.

<bblfish> IT also constrains the GET

<sandro> (this is independent of possible variablity in protocol behaviors, like silent failure of DELETE)

<bblfish> +1

<JohnArwe> I think we also need to MUST that on 4xx responses that fail due to violation of the constraints.

<davidwood> +0.5, I would really like to see an RDF vocab developed and used for these descriptions

<roger> +1 and I beleive we need to do this for POST at this stage too.

<ericP> +1

<sandro> the constraint is on the possible graph shapes -- so it affects GET and PUT and PATCH.

<nmihindu> +0.5 for the same reasons as davidwood

<sandro> +1

<SteveS> +1

<sandro> The absense of this header means the absense of such a constraint.

<nmihindu> +0.5 - mesteban for the same reasons as davidwood

<sandro> +0.5

<Ashok> 0.5 also want to see protocol constraints

<bblfish> +0.5 I think in HTTP one can do things like that.

<Arnaud> RESOLVED: When a server answers a GET or HEAD on an LDPR for which the RDF graph is somehow constrained MUST include a Link header giving a URL for the given constraint. We wont actually specify at this time how those constraints are specified. Natural language is okay for now. The absense of this header means the absense of such a constraint.

<Arnaud> RESOLVED: When a server answers a GET or HEAD on an LDPR for which the RDF graph is somehow constrained it MUST include a Link header giving a URL for the given constraint. We wont actually specify at this time how those constraints are specified. Natural language is okay for now. The absense of this header means the absense of such a constraint.

<JohnArwe> Proposal: we also MUST that on 4xx responses that fail due to violation of the constraints.

<bblfish> +1 that we should specify what error messages happen on partial acceptance

<Zakim> JohnArwe, you wanted to get consensus on 4xx proposal

<sandro> +1 so you can see what caused the failure

<davidwood> +1

<nmihindu> +1

<bblfish> +1

<roger> +1

<SteveS> cody +1

<ericP> +1

<SteveS> +1

<nmihindu> +1 for mesteban

<bblfish> ah I see

<Arnaud> RESOLVED: servers MUST also have that header on 4xx responses that fail due to violation of the constraints.

<bblfish> one gets the constraint header on a 40x or 208.5 if there was an error on constraint

RESOLUTION: servers MUST also have that header on 4xx responses to any verb (PUT, POST, etc.) that fail due to violation of the constraints.

<bblfish> +1 for better wording by TallTed

sandro: this explicitly bifurcates LDPRs into constrained and unconstrained. how do we handle relevant specs MUSTs, SHOULDs, etc?

<bblfish> Proposal: Same as above for 208.5

<betehess_mit> are authentication and authorization constraints as well?

<bblfish> betehess_mit: we are dealing with content constraints only

[...chatter...]

<bblfish> betehess_mit: graph constraints, or even mime type constraints I suppose

<betehess_mit> well that's important, because the shape constraints could be based on the user

<JohnArwe> Sandro: does this new header bifurcate the spec further, along the lines of "if your data is constrained, MUST, else 'not MUST'"

sandro: do we now need CLDPRs, CLDPCs?

SteveS: and/or WCLDPRs (writeable)?

JohnArwe: the 208.5 discussion was outcome of "server did sort of what you wanted, and here are the results of what I did"

bblfish: might invent another code where the server returns the triples it didn't accept -- no second GET needed

<JohnArwe> @sandro: see 4.5.1 for current text ... MUST with a MAY escape clause

ericP: maybe we want a request header that says "accept all or nothing -- no 208.5, only 200 or 4xx"

<bblfish> I agree we may not care now.

<bblfish> We should perhaps wait to see if we need it

Arnaud: do we have a use case for this "throw stuff at the wall" scenario?

<bblfish> yes, that was a 203.5

SteveS: I can think of FDA scenarios that want to keep everything possible, but not sure whether that means it keeps *everything*
... the norm is failing when constraints are not met

bblfish: if you want to be flexible, don't put constraints...

Arnaud: I see 2 use cases. want the server to accept anything/everything, or only application-specific.

Ashok: what if you send 100 triples, half validate, half do not... ?

consensus: you should get an error

<bblfish> agree with Arnaud for the moment on the whole for the moment: either make constriants more general if you can accept more, or if you can't accept it all then the client may be trying to say something: eg I want to buy some size xx shoes, and the server accepts that you wanted to buy shoes

sandro: the way we're using it, POST is CREATE, so it has to result in a valid starting state for the created resource

<bblfish> or say I create a command for a minature matchbox car, and the server accepts this and charges me for a 2CV car

sandro: PUT is wholesale replacement, so it also has to result in valid starting state

Arnaud: points to 4.5.4 "... LDPR server could discard triples ..."

<bblfish> yes we can always add a 203.5 later

sandro: I think we're leaning toward the server MUST accept all or none, partial silent discard is a definite issue

cody: if I have a commenting engine (v1), with a certain schema. at some point, (v2) two properties are no longer relevant, so schema has changed, and clients are now submitting useless fields
... don't want to have to update all clients to update the server

<bblfish> ok, I agree the use case makes sense

SteveS: if I GET a resource (bug report), modify it, PUT back -- want system to ignore the "date I got it"

<JohnArwe> I also poked cody to make sure this is captured in UC&R; if we forgot it once, we'll do so again ;-)

Arnaud: so we have use cases for this. how do we address it?

<bblfish> can we write up that use case in detail?

<SteveS> bblfish, who are you asking?

<SteveS> which use case?

JohnArwe: could add new status code; use warning header (nobody uses it, but it's defined); go to soft vs hard requests; else?

<bblfish> the use case where the server changes and stops accepting certain fields. What kind of fields wree thought to be unimportant later?

JohnArwe: two proposals -- can use existing status codes when client intent is known. harder to address when client intent unknown.

<SteveS> The spec lists some of them, prime example is dc:modified or modifiedBy, these are things that a server computes on write. A client would have these in the content it GETs and would need to strip these "server managed" before PUTing back the content, with modified prroperty

[ ... discussion about response codes ... ]

bblfish: trying to order a matchbox car shouldn't result in ordering a full-size, so need the "all or nothing" request ability

sandro: none of the existing 2xx codes fit what we want

<bblfish> http://en.wikipedia.org/wiki/Http_error_codes#2xx_Success

<bblfish> 207 Multi-Status (WebDAV; RFC 4918)

<bblfish> 208 Already Reported (WebDAV; RFC 5842)

<bblfish> 226 IM Used (RFC 3229)

<bblfish> I am not suggesting those, just saying that others have created new 20x codes

<bblfish> here http://en.wikipedia.org/wiki/Http_error_codes#2xx_Success

<bblfish> Arnaud:

<davidwood> https://en.wikipedia.org/wiki/List_of_HTTP_status_codes

Arnaud: we're agreed we don't want to leave the spec as-is, with silent failure

<bblfish> +1 we don't leave things as is

<Arnaud> PROPOSED: change the spec, somehow, so that in case the server discards some of triples the client sent it informs the client

<SteveS> +1

<nmihindu> +1

<sandro> +1 yes we can fallback on to a Link Header, in the worst case

<roger> +1

<SteveS> +1 for Cody

<Ashok> +1

<nmihindu> +1 for mesteban

<Arnaud> RESOLVED: change the spec, somehow, so that in case the server discards some of triples the client sent it informs the client

<Arnaud> ACTION: Steve to investigate how to change the spec so that in case the server discards some of triples the client sent it informs the client [recorded in http://www.w3.org/2013/09/12-ldp-minutes.html#action01]

<trackbot> 'Steve' is an ambiguous username. Please try a different identifier, such as family name or username (e.g., sbattle2, sspeiche).

<Arnaud> ACTION: SteveSto investigate how to change the spec so that in case the server discards some of triples the client sent it informs the client [recorded in http://www.w3.org/2013/09/12-ldp-minutes.html#action02]

<trackbot> Error finding 'SteveSto'. You can review and register nicknames at <http://www.w3.org/2012/ldp/track/users>.

<Arnaud> ACTION: SteveS to investigate how to change the spec so that in case the server discards some of triples the client sent it informs the client [recorded in http://www.w3.org/2013/09/12-ldp-minutes.html#action03]

<trackbot> Created ACTION-93 - Investigate how to change the spec so that in case the server discards some of triples the client sent it informs the client [on Steve Speicher - due 2013-09-19].

<roger> +q to do the same link header we did a while back but for POST instead ...

<Zakim> roger, you wanted to do the same link header we did a while back but for POST instead ...

Arnaud: how about this 4.5.6 "MUST allow PUT"?

<scribe> ACTION: steves to investigate clarified presentation of Client and Server requirements [recorded in http://www.w3.org/2013/09/12-ldp-minutes.html#action04]

<trackbot> Created ACTION-94 - Investigate clarified presentation of client and server requirements [on Steve Speicher - due 2013-09-19].

Arnaud: is there anything else needing discussion in https://www.w3.org/2006/02/lc-comments-tracker/55082/ldp/2833
... what about the DELETE, in 4.6.2?

<bblfish> what are we looking at?

<bblfish> So there is a waitress with whome a server is intimate...

Arnaud: what is the scope of the DELETE method being issued?
... limited to the server being addressed?

bblfish: we delete an LDPR, the created should be deleted from the LDPC... but how do we maintain truth?
... is there a problem if we don't specify something now, that we might have to specify in the future?
... can't spec something now that will break clients in the future

<JohnArwe> Seems to me that 4.6.2 is just a restatement of http, with a tiny bit of specificity to rdf.

bblfish: seems related to the creation ripples -- when you create something, triples may be added elsewhere

JohnArwe: 4.6.2 is LDPR specific, and really restates HTTP

davidwood: when a resource is added to Callimachus, we put it into a named graph, and provenance into another named graph
... deleting the resource, we leave the provenance, but drop the resource's named graph

<JohnArwe> Proposal: make 4.6.2 informative, clarify that it re-states what http allows, and in fact it applies to all methods not just delete.

<SteveS> +1

<davidwood> +1

<nmihindu> +1

<nmihindu> +1 for mesteban

<roger> ++1

<Arnaud> RESOLVED: make 4.6.2 informative, clarify that it re-states what http allows, and in fact it applies to all methods not just delete.

<JohnArwe> +1

<JohnArwe> arnaud points out that this also hits 5.6.2, second sentence

<bblfish> oops

<bblfish> It's late for me

<bblfish> where?

<SteveS> 4.10.2.3

<Arnaud> PROPOSED: change SHOULD to MUST in 4.10.2.3 LDPR servers that initiate paging SHOULD respond to request ...

<JohnArwe> +1

<sandro> +1

<Ashok> +1

<roger> +1

<nmihindu> +1

<davidwood> +1

<SteveS> +1

<nmihindu> +1 for mesteban

<Arnaud> RESOLVED: change SHOULD to MUST in 4.10.2.3 LDPR servers that initiate paging SHOULD respond to request ...

<SteveS> +1 for Cody

<davidwood> http://www.ietf.org/rfc/rfc2616.txt in Section 14.30 (Location header)

<bblfish> The meaning of Location header has changed in the latest http 2.0 specs btw.

<SteveS> Looking at HTTP-bis drafts http://tools.ietf.org/html/draft-ietf-httpbis-p2-semantics-23

<bblfish> http1.1 is out of date

<bblfish> earlier I said: that I noticed that 303 in RDF is required for when one is dereferencing an object that is not an information resource, but that this is not the issue at all here. We are just pointing to another resource. So it could be that the Location header works here.

<bblfish> http://tools.ietf.org/html/draft-ietf-httpbis-p2-semantics-23#section-7.1.2

<bblfish> 7.1.2. Location

<bblfish> The "Location" header field is used in some responses to refer to a

<bblfish> specific resource in relation to the response. The type of

<bblfish> relationship is defined by the combination of request method and

<bblfish> status code semantics.

<bblfish> Location = URI-reference

<davidwood> Location headers also seem to be undefined in http://tools.ietf.org/html/draft-ietf-httpbis-p2-semantics-23#section-7.1.2

<bblfish> http://tools.ietf.org/html/draft-ietf-httpbis-p2-semantics-23#section-7.1.2

<JohnArwe> I would truly love it if TallTed is able to locate something indicating that 200+Location is usable for our purposes.

<JohnArwe> ...have wished for same thing myself.

<bblfish> ok, guys its close to midnight here

<bblfish> (wavE)

<Arnaud> trackbot, end meeting

- DRAFT -

Linked Data Platform (LDP) Working Group Teleconference

12 Sep 2013

Attendees

Contents

F2F Agenda Review

Specification last call comments

Mark Baker's comment LC-2812

LC-2815 (Ashok)

LC-2816

LC-2813

Primer

TimBL's comments

Summary of Action Items

Scribe.perl diagnostic output