Linked Data Platform (LDP) Working Group Teleconference -- 18 Jun 2012

<trackbot> Date: 18 June 2012

<scribe> scribe: Alexandre

<scribe> scribenick: betehess

Arnaud: welcome everybody

Arnaud: for the first cll, thought it would be useful to see how we'll proceed
... worked with the staff to see how we'll do that

Arnaud: when we have no remaining issues, then we're done
... in term of expectation, we are driven by the charter
... it sets the scope and deliverables
... there are 4 of them
... there is a note about ACLs
... as some people said it was an important issues, other people disagreed
... because it may consume too much resource
... the note was a compromise
... the last deliverable is a test suite

<dret> yes, i will try to do so, we will talk about how to update use cases and requirements later. everybody should have the opportunity to contribute.

Arnaud: for me, the note and the TS are secondary for now
... we need to focus on the spec
... we have a starting point: the IBM submission
... we'll develop from it
... we have some use-cases as well
... we're free to change whatever we need, even though this is the starting point (as it's said in the charter)

<mhausenblas> I think we really need to put some efforts into the UC (and derive requirements, properly)

Arnaud: we need to identify the questions and see how the Submission answers them
... sure that you guys have plenty of questions

<dret> yes, that's the first big task for the group. what exactly are we doing; what are we not doing?

Arnaud: that's a practical way to get started
... we stay focus on producing a set of documents
... sounds reasonable?
... we can also considerer other materials
... I welcome any reference to them

<dret> who is there?

Arnaud: there may be other ways to do things
... it's useful to have these references
... eg. the sparql graph store protocol
... there is obviously some overlap
... if there is a good reason to compete there, we need to document it

dret: good intro, welcome everybody

Arnaud: for today, we want everybody on the same page
... Steve will give you an overview of the Submission

<AndyS> s/@@/Steve Speicher/

SteveS: how should I proceed? should I just take questions?

Arnaud: depends on the team. just make sure it's recorded

<MacTed> +1 skim to start, inline questions if necessary, issues and more detailed feedback later...

<Yves> issues needs to be on the ML

Arnaud: there is a bot on IRC to record issues

Yves: for issues, the best is to start with an email on the ML
... so that we can refer to it from trackbot
... then you can put the reference in IRC

Arnaud: ok
... so if people are questions, just raise them on IRC
... for real issues, please send an email to the list

<SteveS> Member Submission envelope page http://www.w3.org/Submission/2012/02/

<SteveS> Use case and requirements http://www.w3.org/Submission/2012/02/

<mhausenblas> BTW, the tracker for this WG is here: https://www.w3.org/2012/ldp/track/

SteveS: that's a like to the cover page of the Member Submission

<SteveS> http://www.w3.org/Submission/2012/SUBM-ldbpucr-20120326/

Submission walk-through

SteveS: want to focus on why this is important for us
... related to the workshop we had
... my background is system integration

<olberger> mhausenblas: https://twitter.com/#!/sspeiche too

SteveS: I'm doing that at IBM
... our problem was integration between tools
... we needed some glue code for the data
... and we needed to work with 3rd parties
... data was spread in different silos
... very limited success
... we started with "rules" from timbl

[steve is going through their experience and needs at IBM]

<olberger> IBM Rational

SteveS: we need gather lots of different data

Arnaud: we'll all contribute to this document
... maybe we could move this content to a wiki page?
... erik, how do we work?
... only one person who edits the page? or everybody can?

<MacTed> +1 chaotic wiki to start, organized polish later

<cgueret_work> +1 to everyone edit

SteveS: who's taking the action?

Arnaud: I will
... so to get started, people can add their use-cases
... then we can review as a group what belongs there

dret: ok

<SteveS> Linked Data Basic Profile 1.0 Member Submission - http://www.w3.org/Submission/2012/SUBM-ldbp-20120326/

Arnaud: let's move on to the spec

<olberger> http://www.w3.org/Submission/ldbp/

SteveS: this documentation tries to capture some of the requirements and use-cases
... we look at patterns that have emerged
... http/rdf best practices

<steveP> it's SteveP talking now, not me

SteveS: how to read linked data
... we don't go through acls, security, etc.
... or schema-like things
... some terminology: we made sure we didn't create anything new
... if we do so, we define the terms
... jump to section 4
... what are resources in this context?

<ericP> SteveS, we introduce Basic Profile Resource and Basic Profile Container

<ghard> Aren't the container hierarchies already sufficiently expressed in SIOC/AtomOWL?

SteveS: what are the relationship with the type of resources, the value types, the vocabulary
... some stuff is already defined in HTTP
... RDF is not the only thing
... stable urls are used across definitions of the resource
... the response must have the right urls to help not having different names
... people must be speaking about the same things
... there are some requirements about RDF type
... you should not have to infer it
... keep it as simple as possible
... uris are resolvable, hence the use of http
... we can provide an rdf schema to know more about the data

<ericP> SteveS: we restrict ourselves to a set of known datatypes

SteveS: use triple for relationships between resources

<ericP> ... (instead of inventing a link relationship)

SteveS: don't create a weird machinery
... etags should help for caching scenarios

<olberger> 4.2 : verbs

SteveS: so of course, GET must be supported
... there are questions about which serialisations to support

<ericP> ... MUST support application/rdf+xml, SHOULD support text/turtle

SteveS: the type of the resource is not expected to change
... the etag questions was raised on the ML by leigh dodds

<cygri> commonscribe++

mhausenblas: some WG started to use commonscribe, but no problem here

ericP: how complex is it?

<mhausenblas> http://www.w3.org/2009/CommonScribe/

mhausenblas: ask sandro

ericP: I'll do

SteveS: section 4.3

<ericP> ACTION: ericP to ask sandro about how difficult it is to set up CommonScribe [recorded in http://www.w3.org/2012/06/18-ldp-minutes.html#action01]

<trackbot> Created ACTION-1 - Ask sandro about how difficult it is to set up CommonScribe [on Eric Prud'hommeaux - due 2012-06-25].

SteveS: http post works as expected....

<olberger> mhausenblas: obviously not ;)

SteveS: http put brings some problems, like how to deal with state and modifications
... 4.4 defines the expected behaviour
... want to ensure that data can be updated

<Zakim> mhausenblas, you wanted to ask about process

mhausenblas: what is the possibility re: handling issues?

<ericP> MIG531 has Sandro

mhausenblas: someone raises one and the chairs is the one deciding if it's reasonable?

Arnaud: good question
... let's be democratic
... so I'm tempted to let anybody to bring issues

mhausenblas: raising issues is cheap, anybody can to it
... but who decides how to go from 'raised to 'open?

<ghard> +1 be easy on raising issues. Can amend policy later if proves infeasible.

mhausenblas: does not have to be decided now, just need a policy

<MacTed> +1 anyone RAISE; Chair may arbitrarily bump to OPEN; WG as whole should decide to reject/close/ignore/etc....

mhausenblas: everybody should be able to raise issues
... and then let the chairs to accept them
... to make sure we're not going out of scope

dret: sounds reasonable

<ericP> PROPOSED: anyone may RAISE and issue, chairs may OPEN CLOSE, REJECT, etc

<mhausenblas> +1

Arnaud: yes, also people can alway complains if something going wrong

<Yves> +1

<ghard> +1

<ericP> PROPOSED: anyone may RAISE an issue, chairs may OPEN CLOSE, REJECT, etc

<SteveS> +1

<JohnArwe> +1

<cygri> +1

<MacTed> +0

<svillata> +1

<Andras> +1

<ericP> APPROVED

<ruben1> +1

<dret> +1

<Arthur> +1

SteveS: of course, DELETE means delete

Summarizing remaining bits of LDBP

SteveS: it may affect other things
... PATCH is a good way to do things, but we have no solution here yet

<ericP> SteveS: we've not supplied a proposed PATCH format

<ericP> ... there's a TurtlePatch on the W3C wiki

SteveS: we're still experimenting

<ericP> ... we're working on somthing of our own and are happy to bring it to the group

<Yves> note that we need to test things, so having a patch format (even incomplete) would be useful

SteveS: re: Container, I won't go into details
... it reflect the patterns we've observed
... eg. how you get list of resources

<ericP> SteveS: factory URLs are the same as Container URLs

SteveS: especially when they are big
... also, you don't always want to fetch all urls you found
... there are examples for that
... the Containers also deal with how to create resources
... and see how it relates to the model
... there is an example to get the container with content
... 4.5.2 deals with retrieving partial data
... you say what you're interested in

<SteveS> GET /container1?non-member-properties HTTP/1.1

<SteveS> Host: example.org

<SteveS> Accept: text/turtle; charset=UTF-8

SteveS: just pasted an example from the spec
... where you say what property you're interested in
... 5.1.3 allows paging
... can be decided by the server

<ericP> http://example.org/container1?firstPage

SteveS: so you need to go back to the server to get the rest
... we found that there are other things that you may want to do
... we kept it simple
... also, performance are important

<ghard> 206 partial content?

<ericP> server passed back a document with identifies bp:nextPage, e.g. http://example.org/container1?p=2

<mhausenblas> Michael: Wondering if we can really re-use RFC5005 as pointed out by dret - will you raise an issue on that, dret?

<ghard> k

SteveS: there are other models than that

<ericP> SteveS: i think 206 involves splitting a document

<olberger> RFC 5005 - Feed Paging and Archiving

SteveS: re: ordering, again, there are other solutions
... interesting in OLO

<ericP> Ordered List Ontology

SteveS: the model already has the predicates
... the server can include new statements
... the default ordering is the one in SPARQL

Arnaud: thank you steve
... best way to ask questions: send them to the list

<dret> generally speaking, we should raise the question of how much we want to reuse existing machinery/standards

Arnaud: I'd like to ask people to send reference to related work
... graph store protocol is a w3c spec, so we really cannot ignore it

<ericP> http://www.w3.org/2012/01/http-rdf-update/#http-post -> SPARQL 1.1 Graph Store HTTP Protocol

Arnaud: maybe LeeF can bring some history here?
... maybe not on the phone

<ghard> http://sioc-project.org/ontology re containers

<mhausenblas> dret, what would the answer to such a question be? as much as possible? I don't think it makes sense in the general case. we need to write down the requirements (based on the UC) and of course we should re-use as much as possible and avoid NIH syndrome :)

<sandro> ACTION: sandro set up commonscribe [recorded in http://www.w3.org/2012/06/18-ldp-minutes.html#action02]

<trackbot> Created ACTION-2 - Set up commonscribe [on Sandro Hawke - due 2012-06-25].

ericP: sandro is taking the action re: commonscribe

<JohnArwe> Arnaud: Lee said back at 10:45 he was unable to attend this call

<dret> mhausenblas, NIH is a big risk, but you're right, we need a frame of reference

Arnaud: thank you all
... adjourned

<cgueret_work> bye

<ghard> Bye

<olberger> thanks all

<mhausenblas> Michael: thanks all and looking forward!

RRSAgent:, please generate minutes

<svillata> -svillata

trackbot, end telecon

<AndyS> adjourned

Linked Data Platform (LDP) Working Group Teleconference

18 Jun 2012

Attendees

Contents

Submission walk-through

Summarizing remaining bits of LDBP

Summary of Action Items

Scribe.perl diagnostic output