Chatlog 2013-03-14

See original RRSAgent log or preview nicely formatted version.

Please justify/explain all edits to this page, in your "edit summary" text.

13:09:42 <cody> cody has joined #ldp.
13:09:47 <Ashok> Ashok has joined #ldp.
13:09:52 <bblfish> Mh, the background noise restarted. Somone should call in from a normal phone and just see if that's just my problem.
13:10:01 <nmihindu> Scribe: nmihindu
<nmihindu> chair: Arnaud
13:10:24 <nmihindu> TOPIC: Plan for the day
13:10:47 <krp> krp has joined #ldp.
13:11:01 <nmihindu> Arnaud: first half hour of the day for break out sessions
13:11:42 <nmihindu> ... people propose topics in the whiteboard and we can decide which ones we want to tackle
13:12:58 <nmihindu> ... we have (1) binary resources and metadata (2) patch (3) pagination (4) Test suite definition
13:13:41 <bblfish> ah good the noise has gone
13:13:42 <bblfish> nice
13:14:35 <nmihindu> ... the expectation of the breakout sessions is to come up with a proposal to the aforementioned issues
13:15:34 <bblfish> they are all intersting, indeed
13:16:28 <nmihindu> ericP: we already have a session allocated for test suite already
13:16:43 <SteveBattle> SteveBattle has joined #ldp.
13:17:02 <nmihindu> rgarcia: my idea was to come up with a concrete schema for the tests
13:17:44 <nmihindu> ericP: I already have put one in the list
13:18:29 <nmihindu> Arnaud: we would do the test suite during the session in the agenda and decide we still need breakout session for that
13:19:14 <SteveBattle> q+
13:19:15 <nmihindu> cygri: may be can do the pagination breakout session in parallel with access control wg session
13:20:03 <TallTed> TallTed has joined #ldp.
13:20:10 <roger> roger has left #ldp
13:20:30 <nmihindu> Arnaud: moving up the test suite discussions to 11.30 in the agenda  http://www.w3.org/2012/ldp/wiki/F2F1
13:21:18 <nmihindu> SteveBattle: there are comments in the public list, are we going to talk about that ?
13:21:26 <SteveBattle> q-
13:21:27 <ericP> s/http:\/\/www\.w3\.org\/2012\/ldp\/wiki\/F2F2/http:\/\/www.w3.org\/2012\/ldp\/wiki\/F2F2/
13:21:41 <nmihindu> Arnaud: we will talk about that during the day
13:22:55 <nmihindu> Arnaud: after lunch, we can decide whether we need more time for breakout sessions. We can do changes on the fly to the agenda if necessary.
13:23:03 <TallTed> :-)
13:23:14 <nmihindu> TOPIC: Access Control WG Note
13:24:25 <nmihindu> Arnaud: Access Control WG Note is in the charter but not in the recommendation track
13:24:42 <nmihindu> ... we already started with a wiki page
13:25:14 <bblfish> http://www.w3.org/2012/ldp/wiki/AccessControl
13:25:35 <nmihindu> ... the expectation for today is see where are we today, and what are the steps necessary for us to get to the point where we can publish as a WG note
13:26:03 <ericP> q+ to ask (SteveBattle) if we have access control use cases
13:26:12 <nmihindu> Arnaud: Ashok, what is your opinion about current status ?
13:26:30 <SteveBattle> No, we do not have access control use cases
13:26:42 <nmihindu> Ashok: we don't talk much about access control is the spec
13:26:44 <Arnaud> ack eric
13:26:44 <Zakim> ericP, you wanted to ask (SteveBattle) if we have access control use cases
13:27:14 <TallTed> ericP - see http://www.w3.org/2012/ldp/wiki/AccessControl#Use_Cases
13:27:14 <nmihindu> ... so what we will get is security which is provided by database or any underlying system
13:27:33 <nmihindu> Ashok: what more do we need ?
13:28:05 <nmihindu> ericP: we need basic access control stuff to ensure interoperability of systems
13:28:44 <bblfish> q+
13:29:07 <Arnaud> ack bblfish
13:29:14 <nmihindu> ericP: if we can provide a standard access control on rdf graph level, there is a standard way to do access control at LDP level
13:29:30 <bblfish> http://www.w3.org/wiki/WebAccessControl
13:29:42 <cgueret> cgueret has joined #ldp.
13:30:25 <bblfish> I am getting background noise again
13:30:42 <nmihindu> bblfish: I already implemented this using web access control and may be we can do that with web access control
13:30:52 <bblfish> got it
13:31:34 <bblfish> We have implemented this a few times. It is extreemly flexible, does not require one Authentication system rather than another, and fits in very nicely with LDP. ACLs can be edited like another LDPR
13:32:01 <nmihindu> Ashok: ericP, so basically you want to say that this group of users can access this, etc ?
13:32:14 <bblfish> So my question is just that I was looking forward to people perhaps who wished to work on it
13:32:20 <nmihindu> ericP: yes, that is a place where we can add some value
13:33:32 <bblfish> What were the three points: (1) Use cases (2) requirements (3) possible candidate technoloiges
13:33:47 <bblfish> s/What were the/Arnaud's/
13:33:52 <nmihindu> Arnaud: I would like to see use cases, requirements, and possible candidates to address this requirements in that note
13:33:53 <ericP> q+ to discuss impact on LDP 1.0
13:34:18 <nmihindu> ... I think that will be sufficient for the note
13:34:32 <Arnaud> ack eric
13:34:32 <Zakim> ericP, you wanted to discuss impact on LDP 1.0
13:34:43 <nmihindu> ... we don't need to tackle interoperabiltiy at this point
13:35:24 <nmihindu> ericP: it might be difficult to facilitate interoperability later on
13:35:46 <nmihindu> if people started using different mechanisms right now
13:36:09 <nmihindu> ... and that would be the impact of not doing it right now with the LDP 1.0
13:36:29 <bblfish> yes, oddly enough I think there is very little needed. An http Link header with rel=acl, an ontology for describing who has access
13:36:43 <nmihindu> Ashok: I can take an action to evaluate that impact
13:37:12 <cgueret> cgueret has left #ldp
13:37:35 <nmihindu> ... you can do access control in different scopes like tuples, pages, etc.
13:37:40 <TallTed> minor structural tweak made to the existing page... may help facilitate evolution
13:38:01 <bblfish> the simplest is page based access control. More gets a lot more complicated
13:39:10 <bblfish> q+
13:39:10 <nmihindu> Arnaud: the document is missing requirements at the moment
13:39:28 <cygri> SteveBattle, I've drafted a use case for pagination, can you please advise what else I need to do to get this included into the UC&R? http://www.w3.org/2012/ldp/wiki/User:Rcygania2/Pagination
13:40:05 <SteveBattle> cygri, I'll take a look.
13:40:19 <nmihindu> ... we can do an analysis on the existing technologies and add it after the candidates
13:40:28 <Arnaud> ack bblfish
13:40:50 <nmihindu> ... we can already start reviewing the use cases in the document
13:41:37 <nmihindu> bblfish: we can do a strawpol to see whether people are like to work on web access control stuff ?
#13:42:18 <bhyland> bhyland has joined #ldp.
13:42:19 <nmihindu> Arnaud: we are mainly focused on getting the WG note getting published
13:42:57 <nmihindu> ... people interested in web access control can get in touch with Henry and work on that too
13:43:35 <nmihindu> bblfish: I know few people are interested in web access control in the group
13:43:44 <bblfish> yes, understood.
13:44:15 <nmihindu> Arnaud: I would like to have some volunteers to review the document
13:44:27 <bblfish> I'll volunteer to re-look at the use cases more carefully.
13:44:36 <nmihindu> ... and report back to the group the status of the document
13:44:51 <bblfish> ( as I am starting to have a good feeling of what one can do )
13:45:43 <nmihindu> Arnaud: ericP and roger volunteer to review the document
13:46:27 <bblfish>  Anyway: it's a good idea use case and requirements are a first step to doing anything serious :-)
13:46:32 <nmihindu> ... are we going to have a time-frame for reviewing the document ?
13:46:55 <Arnaud> action: ericP and roger to review the Use Cases section of the document
13:47:03 <trackbot> Created ACTION-47 - And roger to review the Use Cases section of the document [on Eric Prud'hommeaux - due 2013-03-21].
13:48:10 <Arnaud> action: ashok to take a first crack at the requirements of Access Control note
13:48:14 <trackbot> Created ACTION-48 - Take a first crack at the requirements of Access Control note [on Ashok Malhotra - due 2013-03-21].
13:48:50 <nmihindu> ... do we need to do anything more on the document ?
13:49:32 <nmihindu> ... it is open to discussion but better to be finished with the use-cases and requirements
13:50:00 <Arnaud> q?
13:50:01 <nmihindu> ... the default deadline would be in two weeks
13:50:14 <bblfish> I am ok, with it.
13:50:17 <nmihindu> ... any other comments on this one ?
13:50:47 <nmihindu> TOPIC: Deployment guide
13:51:07 <nmihindu> Arnaud: this is also an optional deliverable
13:51:45 <nmihindu> ... the goal is to understand the status as of today, and what we want to do, and the plan to get there
13:52:48 <nmihindu> ... the goal of the document is to provide best practices for the implementers
13:52:54 <cgueret> cgueret has joined #ldp.
13:53:14 <cody> "Deployment Guide" to me is sort of misleading as a title.
13:53:27 <nmihindu> ... we already moved some sections of the spec like data types etc. to the deployment guide
13:53:27 <cygri> q+
13:53:37 <SteveS> cody, suggestion for a better name?
13:53:45 <Arnaud> ack cygri
13:53:45 <bblfish> http://www.w3.org/2012/ldp/wiki/Deployment_Guide
13:53:54 <nmihindu> ... what do we need to make it a document that we can publish ?
13:55:06 <nmihindu> cygri: having this as a separate document is a good thing because we can keep the strict protocol things in the main spec and best practices to the deployment guide
13:55:08 <cody> …thinking of a recommendation for title.
13:55:45 <nmihindu> ... we can decide what we need to put there as we go as we discover the best practices and any guidelines that are useful
13:56:20 <bblfish> ( but I can hear Arnaud very well )
13:56:27 <nmihindu> ... we don't need to put more effort than that
13:56:56 <bblfish> s/^/\/me/
13:57:03 <nmihindu> Arnaud: I agree. We can move the best practices to the document so they don't get lost
13:57:14 <rgarcia> bblfish, Arnaud is closer to the mic
13:57:20 <nmihindu> ... do we have any volunteers for that ?
13:57:24 <bblfish> rgarcia: thanks, that makes sense
13:57:47 <nmihindu> cygri: I volunteered for this already
13:57:57 <cody> Something more like "LDP Auxiliary Guidelines and Recommendations"
13:58:12 <cody>  Auxiliary:
13:58:12 <cody> Adjective
13:58:12 <cody> Providing supplementary or additional help and support: "auxiliary airport staff".
13:58:27 <cody> Noun
13:58:28 <cody> A person or thing providing supplementary or additional help and support.
13:59:17 <nmihindu> cygri: I don't expect to much effort in this document
13:59:44 <nmihindu> s/expect to much/expect much
14:00:14 <nmihindu> roger: implementation guide would be a good name
14:00:50 <nmihindu> cygri: best practices and implementators' guide ?
14:00:54 <cygri> maybe a better name: LDP Best Practices and Implementer's Guide
14:01:10 <cody> +1 better
14:01:19 <nmihindu> Arnaud: we can always change the name later
14:02:02 <nmihindu> ... that is something editors can propose
#14:02:36 <jmvanel> jmvanel has joined #ldp.
14:02:37 <nmihindu> JohnArwe: if you don't like something that is in the document, you should propose something better
14:02:44 <SteveS> +1 the name is better
14:04:10 <nmihindu> Arnaud: for formatting stuff, taking a look at the specification would be helpful
14:04:34 <SteveBattle> What about xdd:int?
14:04:42 <SteveBattle> s/xdd/xsd/
14:05:25 <nmihindu> cody: do we use the discussion tab on the documents ?
14:06:06 <nmihindu> Arnaud: no, we are using the mailing list for discussions
14:06:59 <Arnaud> action: cygri to turn the deployment guide/best practice wiki page into a first draft note for publication
14:06:59 <trackbot> Created ACTION-49 - Turn the deployment guide/best practice wiki page into a first draft note for publication [on Richard Cyganiak - due 2013-03-21].
14:07:07 <SteveBattle> Specifically, can we add xdd:int to the list on the screen right now.
14:07:10 <SteveBattle> s/xdd/xsd/
14:07:36 <nmihindu> ... any other comments on deployment guide document ?
14:08:08 <cygri> SteveBattle, I'd argue against including xsd:int there. The limited-range datatypes are potentially useful when specifying ranges, but not in instance data
14:07:57 <nmihindu> TOPIC: Public lists of LDP
14:08:29 <nmihindu> Arnaud: is everyone of the WG subscribed to the public list ?
14:08:48 <betehess> betehess has left #ldp
14:09:33 <nmihindu> ... we had the public list for open to everyone when we are creating the charter
14:10:32 <nmihindu> ... once the work group has started, we created the private list mainly to tackle legal issues about contributions
14:11:02 <SteveBattle> Many people recommend avoiding the unbounded xdd:integer, preferring instead the 32-bit xsd:int
14:11:20 <cygri> SteveBattle, that's in XML schemas I suppose
14:11:20 <nmihindu> ... to avoid patent issues etc.
14:11:20 <SteveBattle> stupid spell-checker
14:11:55 <SteveBattle> s/xdd/xsd/
14:11:56 <nmihindu> ... it helps to separate and differentiate the members of the group
14:12:15 <roger> roger has joined #ldp.
14:12:25 <nmihindu> ... but the list is still open to subscribe but they can not post
14:13:07 <nmihindu> ... we decided use the public list for posting comments too
14:13:54 <nmihindu> ... so it is important that we subscribe to the public list too
14:14:52 <nmihindu> TallTed: the mailing list patterns used by our group in not the norm in W3C WGs
14:15:41 <nmihindu> sandro: we need to formally respond to every comment
14:16:07 <nmihindu> ... so may be using the same list for public comments is not the best option
14:16:22 <nmihindu> ... but we have the option of changing this in the last call
14:16:51 <AndyS> AndyS has left #ldp
14:17:02 <nmihindu> Arnaud: may be we can create a comment list when we come to the last call
14:17:40 <nmihindu> sandro: do we need to do something about the people who are subscribed to private list but not the public list ?
14:17:59 <betehess>  laptophas joined #ldp.
14:18:16 <nmihindu> Arnaud: there is no need to force, but I just wanted to make sure that everyone is aware of the public lists
14:19:20 <bblfish> can somone help me see if the microphone can be placed a bit better so I can hear everyone?
14:19:34 <TallTed> bblfish - it's as centrally placed as possible
14:19:49 <bblfish> ah is it perhaps an issue of getting the microphone to be more sensitive?
14:20:05 <bblfish> ( not sure if that can be tuned )
14:20:27 <TallTed> not an option on this device
14:20:41 <rgarcia> rgarcia has left #ldp
14:21:09 <bblfish> Ok, perhaps if people speak up a bit more that would help.
14:21:45 <bblfish> Somone said the phone is closer to Arnaud than to other people.
14:22:28 <betehess> betehess has left #ldp
14:22:46 <Arnaud> ok, henry, I'll try to remind people to speak up
14:26:14 <roger> roger has left #ldp
14:31:07 <SteveS> SteveS has left #ldp
14:41:32 <roger> roger has joined #ldp.
14:45:37 <roger> roger has left #ldp
14:47:25 <SteveS> SteveS has joined #ldp.
14:48:00 <rgarcia> rgarcia has joined #ldp.
14:49:20 <rgarcia> scribe: rgarcia
<rgarcia>topic: Test suite & Validator
14:50:17 <rgarcia> Arnaud: we have to produce a test suite, the validator is not compulsory
14:51:03 <rgarcia> ... we decided to use EARL and Eric started developing a framework
14:52:09 <rgarcia> ... let's see what Eric did as a starting point
14:52:19 <cody> http://www.w3.org/2012/ldp/wiki/Testing
14:53:03 <rgarcia> ... we need a link to the repository
14:53:14 <rgarcia> q+
14:53:53 <Arnaud> ack rgarcia
14:55:37 <SteveBattle> q+
14:56:13 <Arnaud> ack steveb
14:56:13 <bblfish> q+
14:56:44 <rgarcia> rgarcia: I included in the wiki a proposal on how can tests and results be described
14:57:18 <Arnaud> ack bblfish
14:57:29 <ericP> -> https://dvcs.w3.org/hg/ldpwg/file/tip/tests/basic/Manifest.ttl strawman manifest.ttl
14:57:44 <rgarcia> bblfish: alexander wanted to participate in this part
14:58:00 <rgarcia> ericP: Let's put both proposals side by side to compare them
14:58:29 <davidwood> davidwood has joined #ldp.
14:58:29 <rgarcia> rgarcia: my proposal just reuses existing vocabularies and add some more things from the W3C recommendations for tersting
14:58:44 <rgarcia> s/tersting/testing/
14:59:03 <rgarcia> ericP: describes the example test suite
#14:59:03 <jmvanel> jmvanel has left #ldp
15:00:09 <betehess>  laptophas joined #ldp.
15:00:37 <rgarcia> ... tried to use C names for identifiers
15:02:50 <rgarcia> ... right now does not include response code and response content
15:03:24 <bblfish> IS there a URL to the TriG?
15:03:37 <rgarcia> ... the final state of a test is the initial state of the next one
15:04:27 <betehess> betehess has left #ldp
15:04:37 <rgarcia> bblfish, is a reference to a local file (relative URL)
15:06:26 <SteveBattle> q+
15:06:56 <krp> krp has left #ldp
15:07:16 <bblfish> ah ok the TriG are in hg as for eg: https://dvcs.w3.org/hg/ldpwg/file/tip/tests/basic/NetWorth_0_4.trig
15:07:25 <rgarcia> ... the test harness must know the server to get the information about the expected result
15:08:44 <rgarcia> ... the harness must reset the server to a known state
15:09:20 <rgarcia> ... then the harness post a message to the server
15:10:34 <rgarcia> sandro: the harness must have a backdoor access to the serves
15:10:42 <rgarcia> davidwood: or just make a GET to the container
15:11:32 <rgarcia> ericP: then the harness gets the final state in the server and compares it with the expected state
15:11:36 <bblfish> The final state https://dvcs.w3.org/hg/ldpwg/file/tip/tests/basic/NetWorth_1_4.trig
15:12:37 <roger> roger has joined #ldp.
15:14:57 <Arnaud> ack steveb
15:15:29 <mesteban> q+
15:15:37 <SteveS> q+
15:15:52 <bblfish> yes, perhaps the end state should be a SPARQL query to test the resulting graph
15:16:10 <bblfish> where the SPARQL would have relative URLs with respect to the created resource for example
#15:16:54 <jmvanel> jmvanel has joined #ldp.
15:17:07 <bblfish> The SPARQL ASK seems like a good idea.
15:17:15 <rgarcia> ericP: mentions alternatives followed in SPARQL and RDFa, e.g., based on SPARQL ASKs
15:18:00 <Arnaud> ack mesteban
15:18:28 <rgarcia> mesteban: describing the whole state is putting a lot of restrictions in the server
15:18:44 <rgarcia> ... having assertions can simplify this
15:18:49 <davidwood> +1
15:19:11 <Arnaud> ack steves
15:19:25 <davidwood> q+ to ask why not store a SPARQL query in the TriG to test results.
15:19:45 <rgarcia> SteveS: add traceability to the spec
15:21:03 <SteveBattle> My question was that a typical test framework would only test for specific properties of the result rather than test full graph equivalence.
15:21:14 <sandro> q?
15:21:15 <sandro> q+
15:21:55 <rgarcia> q+
15:21:57 <SteveS> I also wanted to make sure the framework executes/reports separately on MUST/SHOULD/MAY
15:22:27 <rgarcia> SteveS, we can categorize tests in their metadata descriptions
15:22:44 <rgarcia> Arnaud: do we extend time discussing tests?
15:22:48 <krp> krp has joined #ldp.
15:23:15 <Arnaud> ack david
15:23:15 <Zakim> davidwood, you wanted to ask why not store a SPARQL query in the TriG to test results.
15:23:21 <rgarcia> ... which is the path forward for the next minutes?
15:23:40 <rgarcia> davidwood: we did something similar with turtle in callimachus
15:24:34 <Arnaud> ack sandro
15:24:58 <rgarcia> sandro: the complexity terrifies me
15:25:15 <rgarcia> ... and I don't like having backdoors in servers
15:25:23 <rgarcia> ... need a validator
15:26:07 <nmihindu> +1 for not requiring servers to have backdoors for running these conformance tests
15:26:46 <rgarcia> ericP: backdoors are for initial and final state
15:27:04 <bblfish> is the problem that you need access control to get the data, and that this is why you need back doors?
15:27:44 <rgarcia> Ashok: why not getting a GET?
15:27:49 <bblfish> +1
15:28:30 <bblfish> Some things would be difficult to test indeed.
15:28:55 <rgarcia> sandro: new features will require new test types
15:29:17 <sandro> q+ eric
15:29:46 <Arnaud> ack rgarcia
15:30:05 <davidwood> The complexity is the use case for embedding SPARQL queries - that gives you a way to arbitrarily test the final states using a standard mechanism.
15:30:44 <bblfish> +1 with Rgarcia: one should be able to run the whole test suite using LDP itself, using GET, POST, etc...
15:30:53 <sandro> rgarcia: I want the testing to be through the normal operations, not reaching around/inside the tested item
15:30:56 <Arnaud> ack eric
15:31:38 <sandro> rgarcia: Having the output of one test be the input of another is a problem.
15:31:45 <bblfish> q+
15:31:54 <sandro> Arnaud: the backdoor to reset state could fix that.
15:32:34 <rgarcia> rgarcia: I don't like the backdoor, I would prefer only using the LDP operations to interact during testing (black box)
15:32:38 <roger> roger has left #ldp
15:32:59 <rgarcia> ... testing should also cover the protocol level (e.g., status codes returned)
15:33:11 <rgarcia> ... and tests should be independent
15:33:28 <Arnaud> ack bblfish
15:33:57 <roger> roger has joined #ldp.
15:34:18 <rgarcia> bblfish: the initial state could be having just an empty container
15:34:38 <davidwood> yes
15:34:49 <rgarcia> ericP: this is what current tests do, but it is not required to be like that
15:35:29 <bblfish> If you start with that, then one would not need to have a backend access to the server.
15:35:53 <rgarcia> ericP: can we expect that we can create containers in servers unowned by us?
15:36:12 <rgarcia> Arnaud: we will continue with the breakouts
<rgarcia> topic: Breakout sessions
<rgarcia> 3 breakouts take place: 1) binary attachments, 2) pagination, 3) test suite
17:05:40 <davidwood> scribenick: davidwood
<davidwood> topic: Test suite & Validator (continues)
17:05:59 <davidwood> Arnaud: Let's continue the test suite discussion
17:07:17 <davidwood> ericP: waves hands
17:08:22 <davidwood> ericP: The test breakout group talked about how to test generic LDP implementations vs. domain-specific implementations.
17:08:27 <roger> roger has left #ldp
17:08:50 <davidwood> …Some systems will only accept domain-specific data and/or restrictions.
17:09:26 <davidwood> …One solution is to give people a test suite and they give us back some EARL saying what they passed and the data they sent/received.
17:10:34 <davidwood> …These users would need to create their own domain-specific payload.  The only truly generic part would be the REST API.
17:10:57 <roger> roger has joined #ldp.
17:10:57 <SteveS> SteveS has joined #ldp.
17:12:18 <davidwood> …An alternative would be to create a proxy that would have enough knowledge to know how to test each implementation.  A tester would ask the proxy what payload to use for each test before running each test.
17:12:35 <davidwood> Sandro: The knowledge could just be documentation on the Web.
17:12:43 <davidwood> ericP: yes
17:13:07 <davidwood> Arnaud: The solution was even more complicated than we anticipated.
17:14:34 <davidwood> Ashok: When the W3C publishes a spec and someone builds a product, the W3C says that they should say when the tests pass.  Many won't bother.
17:14:41 <sandro> +1 Ashok: beward of making it too hard for them to do the testing....
17:14:52 <Arnaud> q?
17:15:06 <sandro> davidwood: The only reason to test for compliance with a spec is to foster interop
17:15:14 <sandro> .. people don't care about compliance until they hit interop problems
17:15:40 <sandro> .. semweb software doesn't end up hitting this much, because we're mostly operating in small areas
17:15:48 <sandro> .. but sometimes we do hit these problems
17:16:14 <sandro> .. Back in history, TCP/IP, Interop was created for this.   Once there's market pressure, these things emerge.
17:16:35 <sandro> Ashok: Where is SemWeb Interop ?
17:16:35 <bblfish> This would be a reason to add Auth because interop of LDP without Auth is not going to be possible
17:16:41 <ericP> -> http://www.w3.org/2009/sparql/implementations/ implementation report for SPARQL includes 21 products
17:16:41 <davidwood> ericP: The harder it is to pass the tests, the fewer will do it.
17:17:07 <ericP> and the easier it is to do the implementaion report
17:17:09 <davidwood> davidwood: SemWeb interoperability is not in a good state.
17:17:15 <davidwood> Arnaud: What next?
17:17:29 <davidwood> rgarcia: We need to determine how to describe the tests.
17:17:41 <bblfish> Just do the simple tests that start with an empty container, and PUT, POST etc very generic stuff
17:18:09 <davidwood> ericP: I will continue to offer concrete tests for generic endpoints, but they would be tied to particular payloads…maybe.
17:18:40 <davidwood> Arnaud: Just make it as easy as possible to adapt the test suite to a particular domain.
17:18:44 <ericP> s/mabye./maybe?/
17:19:10 <davidwood> Sandro: If we provide a validator that collects inputs and outputs, then it is easy to create a test suite.
17:20:15 <davidwood> Arnaud: We still need to write a generic test suite.
17:20:32 <JohnArwe> +1 to david's question about how one tests implementations that are not themselves web-facing
17:20:58 <JohnArwe> ...anything under devt will not be web-facing at my company
17:21:16 <sandro> my answer: by downloading the python script (or java script??) that you run inside your firewall.       But that's just me.
17:21:44 <davidwood> Arnaud: Can we assign actions?
17:22:12 <Arnaud> action: ericp and rgarcia to come up with a revised proposal for the test suite framework
17:22:15 <trackbot> Created ACTION-50 - And rgarcia to come up with a revised proposal for the test suite framework [on Eric Prud'hommeaux - due 2013-03-21].
17:22:15 <davidwood> ericP: We could create generic tests that can serve as a template for domain-specific tests.
17:22:37 <JohnArwe> if it's really that simple sandro, in principle I think it's fine.  just wanted to bring out the requirement that the source needs to be available for that kind of use.
17:23:27 <sandro> JohnArwe, yeah, I hope it is.    and we need to settle on a programming language/platform.
17:23:54 <davidwood> Topic: LDP Specification - Pending Issues
17:24:50 <roger> roger has left #ldp
<davidwood> subtopic: ISSUE-15: sharing binary resources and metadata
17:25:24 <cygri> ISSUE-15?
17:25:24 <trackbot> ISSUE-15 -- sharing binary resources and metadata -- open
17:25:24 <trackbot> http://www.w3.org/2012/ldp/track/issues/15
17:25:24 <davidwood> issue-15?
17:25:24 <trackbot> ISSUE-15 -- sharing binary resources and metadata -- open
17:25:24 <trackbot> http://www.w3.org/2012/ldp/track/issues/15
17:26:34 <davidwood> SteveS: There is a use case for binary resources in the UCR document.  Also see issue-41 (closed)
17:26:44 <davidwood> issue-41?
17:26:44 <trackbot> ISSUE-41 -- Standard way to manage members with attachments -- closed
17:26:44 <trackbot> http://www.w3.org/2012/ldp/track/issues/41
17:26:44 <SteveBattle> http://www.w3.org/TR/2013/WD-ldp-ucr-20130131/#use-case-manage-media-resources
17:27:33 <davidwood> SteveS: Imagine a photo attached to a bug report.
17:27:46 <bblfish> how does a client go from a picture to find metadata about it ( eg: who or what is is in the picture,  who took it, etc )
17:28:14 <davidwood> …The current proposal is for containers to be able to accept any kind of resources.
17:28:46 <davidwood> bblfish, presumably by describing it using RDF in another resource?
17:29:00 <bblfish> indeed
17:29:44 <roger> roger has joined #ldp.
17:30:11 <davidwood> SteveS: The 201 Created response would contain URLs to both the created resource and its metadata in another resource.
17:30:51 <ericP> q+ to ask about having the response to a binary post return the location of the metadata, which in turn points to the binary resource
17:30:58 <davidwood> …POWDER would be used to describe the binaries.
17:31:05 <davidwood> …(maybe)
17:31:16 <bblfish>  Link: <pix>;meta>; rel=meta
17:31:25 <bblfish> you can get all the existing rel links here http://www.iana.org/assignments/link-relations/#
17:31:44 <bblfish> And it is easy to add a new one if one does not find one that fits
17:32:27 <davidwood> SteveS: You can always perform a HEAD on the binary to get a link to the metdata.
17:32:32 <davidwood> s/metdata/metadata/
17:32:58 <bblfish> RFC5988 http://tools.ietf.org/html/rfc5988
17:33:37 <ericP> ack me
17:33:37 <Zakim> ericP, you wanted to ask about having the response to a binary post return the location of the metadata, which in turn points to the binary resource
17:33:37 <bblfish> I think you don't necessarily need the HEAD
17:33:45 <bblfish> perhaps the response returns a link
17:34:35 <davidwood> ericP: The container already refers to resources within it.  Therefore, do we need the separate triples linking binaries and their descriptions?
17:34:44 <bblfish> yes, another solution is to have the container also contain this information.
17:36:19 <SteveBattle> q+
17:36:25 <davidwood> (discussion over alternative designs followed)
17:36:46 <davidwood> TallTed: Have we decided whether containers and contain containers?
17:36:48 <davidwood> (no)
17:37:37 <SteveS> SteveS has left #ldp
17:37:50 <Arnaud> ack stevebattle
17:38:02 <davidwood> ericP: Instead of returning a location for the binary upon a 201 Created, return the location of the metadata.  Force the container to manage the linkage.
17:38:02 <TallTed> POST a binary; server creates container C; returns Location: C, contains binary (I) & description doc (P)
17:38:15 <bblfish> I like that idea of the hash URI in the LDPC
17:38:37 <davidwood> SteveBattle: Doesn't the proposal create additional categories of resources?
17:38:37 <SteveS> SteveS has joined #ldp.
17:38:55 <bblfish>  Link: <.#pix10>>; rel=meta
17:39:00 <bblfish>  Link: <./#pix10>>; rel=meta
17:39:35 <davidwood> Sandro: What happens if you post an HTML document?
17:39:59 <bblfish> so that would point into the Container, then the container could have <> :member> [ dc:author <joe>#me> ... ]
17:40:14 <davidwood> davidwood: We do that.  It is an argument against ericP's design.
17:40:15 <SteveBattle> We considered the case where the returned link is a hash URI within the container, thus avoiding the creation of a redundant LDPR.
17:40:22 <bblfish> oops <> :member> [ = <#pix10>>; dc:author <joe>#me> ... ]
17:40:28 <davidwood> Arnaud: Breakout discussions suck.
17:40:36 <sandro> sandro: yeah, you want your HTML editor to PUT back the web page.
17:40:37 <davidwood> everyone cheers wildly
17:40:58 <Arnaud> s/suck/have some limitation/
17:40:59 <sandro> Arnaud: davidwood is the best scribe ever
17:41:44 <davidwood> Arnaud: Strawpoll
17:42:47 <Arnaud> q?
17:43:07 <mesteban> q+
17:43:07 <cody> q+
17:43:07 <SteveS> Proposal: binary resources posted to LDPC's, generate URL for binary resource and URL in "Link" header for metadata. Include in metadata resource a "describedBy" triple.
17:43:30 <sandro> the breakout approach is: you POST whatever you want to the container, and it gets given a URI I and returned as normal, but ALSO a metadata resources P is created.   When you GET I, you get back a LINK header leading youto P.  When you GET P, there's some triple with the same link information, leading you to I.
17:43:35 <cygri> q+
17:43:47 <davidwood> mesteban: We have seen something for POSTing binaries.  What with DELETEs?
17:44:14 <davidwood> …Does the associated metadata get deleted at the some time?
17:44:19 <Arnaud> ack mesteban
17:44:27 <davidwood> JohnArwe: Hopefully only the member is deleted.
17:44:42 <Arnaud> ack cody
17:44:52 <davidwood> cody: We do we need to connect a binary with a metadata resource?
17:45:11 <bblfish> q+
17:45:17 <JohnArwe> strawman (for the record): delete the object of the membership triple; anything that was created as a side effect also gets deleted as a side effect.
17:45:22 <JohnArwe> q+
17:45:33 <Arnaud> ack cygri
17:46:31 <mesteban> JohnArwe, in our scenario which element is the side effect? The binary or the metadata?
17:46:49 <davidwood> cygri: I am uncomfortable about this because this is complicating POSting to a container.  I won't know whether this server supports POSTing RDF as a binary or RDF content.
17:47:07 <JohnArwe> @miguel, that's why my answer starts with the membership triple.  the object of that triple is the member, defintionally.
17:47:37 <sandro> +0.5 cygri: use an ldp:BinaryContainer so you know which kind this is.
17:48:01 <Arnaud> ack  bblfish
17:48:09 <mesteban> JohnArwe, so in these case the delete should be send to the URL of the metadata, not the URL of the binary file, right?
17:48:14 <davidwood> cygri: You would need to know whether this particular server is an LDP server first.
17:48:32 <cygri> having trouble hearing bblfish
17:48:32 <davidwood> bblfish, we cannot hear you
17:48:37 <TallTed> bblfish - voice connection's broken again
17:48:37 <mesteban> s/send/sent/
17:48:53 <davidwood> bblfish, can you write, please?
17:48:53 <mesteban> s/these/this/
17:48:53 <JohnArwe> @miguel: the membership triple on the board says <c>, member, I> so you'd delete I (which is what you posted in the first place)
17:48:59 <bblfish> I am done
17:49:05 <davidwood> q?
17:49:14 <bblfish> :-)
17:49:14 <mesteban> JohnArwe, I see.
17:49:17 <Arnaud> ack john
17:49:54 <davidwood> JohnArwe: The first part of what Henry said was you have images on the Web. You don't always go through the metadata to get to the image.
17:50:07 <krp> krp has left #ldp
17:50:12 <davidwood> …doesn't agree with cygri.
17:50:33 <davidwood> …Whatever I POST is the thing I am trying to add to a container.
17:50:58 <davidwood> …It is the server's business how to respond.
17:51:26 <bblfish> +1 "…Whatever I POST is the thing I am trying to add to a container."
17:51:37 <davidwood> …It is clear from the use cases that sometimes the client intends to put RDF and sometimes a binary.
17:51:59 <ericP> q?
17:52:03 <davidwood> Sandro: It doesn't matter whether the server understands Turtle for me to POST Turtle.
17:53:03 <davidwood> JohnArwe: The server can set I=P (I for the binary's URL and P for metadata about the binary).
17:53:29 <davidwood> TallTed: The use case for putting things into a container is different from the proposal for this use case.
17:55:21 <JohnArwe> q+
17:55:29 <bblfish> cygri breaks up a lot, perhaps he is not speaking that loudly
17:55:30 <SteveS> q+
17:55:35 <davidwood> cygri: The server is already interpreting RDF (e.g. relative URIs) and may do any amount of clever processing.  In the binary case, I don't want it to manipulate the resource, but it might create metadata.  There is an asymmetry based on which content type is POSTed.
17:56:21 <davidwood> TallTed: The easy way to resolve the asymmetry is for servers to accept any resource the same.
17:56:45 <davidwood> cygri: You may not get the same bytestream back when you GET a resource.
17:56:53 <davidwood> TallTed: The spec may need to change.
17:57:27 <Arnaud> ack john
17:57:34 <davidwood> Arnaud: The asymmetry is handled well with AtomPub (channeling Erik W)
17:58:02 <davidwood> JohnArwe: The asymmetry may be in your head.  Servers can always adjust a resource's bytestream.
17:58:20 <davidwood> +1 to JohnArwe
17:59:11 <davidwood> JohnArwe: You could always choose to return a link to metadata about a resource, but the link might be equal to the resource's URL in many cases.
17:59:17 <SteveBattle> q+
17:59:36 <davidwood> cygri: There may be other forms that return links to RDF metadata.
18:00:04 <Arnaud> ack steves
18:00:28 <davidwood> cygri: Do you always create one URI or do you sometimes create two?  If they differ, there is an asymmetry.
18:00:36 <davidwood> The crowd split into competing factions.
18:01:07 <Arnaud> ack steveb
18:01:40 <davidwood> SteveBattle: How do we replicate the case we have in the UCR?  What about inserting EXIM into a JPEG?
18:01:44 <TallTed> whether you always *create* two URIs is less the question as whether you always *return* two. always return I and P == symmetry (even if I == P)
18:02:06 <davidwood> s/factions/warring factions/
18:02:29 <TallTed> s/competing warring/warring/
18:02:40 <bblfish> I am not sure what the so called asymetry is. Meta data could be useful for LDPRs just as well as for binaries. But for binaries it is more obviously needed
18:02:47 <davidwood> JohnArwe: Hash URIs could be used to access embedded metadata.
18:03:02 <davidwood> SteveS: Does the example need to be updated?
18:03:07 <Ashok> q+
18:03:25 <davidwood> Arnaud: We don't specify how containers need to handle there metadata
18:03:39 <davidwood> Sandro: Containers SHOULD manage metadata for binaries.
18:03:49 <Arnaud> ack ashok
18:03:54 <SteveBattle> I'm not sure the proposed binary scheme can replicate exactly the scenario described in UC&R, it would have to use an indirect hash URI.
18:04:14 <sandro> s/manage metadata for binaries/create metadata resources for non-RDF resources/
18:04:18 <davidwood> Ashok: This may be a standard patter we can extract from LDP.  An HTTP resource could have a link to metadata.
18:04:27 <davidwood> SteveS: Right, we didn't invent that.
18:04:32 <mesteban> s/patter/pattern/
18:05:07 <davidwood> cygri: Does the spec today restrict members of containers to LDPRs?
18:05:10 <davidwood> (no)
18:05:10 <sandro> cygri: LDPCs should be constrained to only contain LDPRs
18:05:17 <JohnArwe> s/patter we/pattern we/
18:05:41 <davidwood> cygri: The client can't make any assumptions about what a container contains.
18:05:47 <davidwood> SteveS: right
18:05:50 <Ashok> s/link/Link Header that points/
18:06:16 <davidwood> Sandro: The spec needs to say clearly what happens when you GET Turtle.
18:06:59 <Ashok> c/patter/pattern/
18:06:59 <davidwood> cygri: If a client only understands one format, it should be possible for them to get something it understands.
18:07:18 <SteveS> SteveS has left #ldp
18:07:18 <davidwood> …Why does binary support need to be in LDP.
18:07:27 <davidwood> …HTTP already defines it.
18:08:12 <davidwood> davidwood: cygri doesn't agree with the use case.
18:08:28 <bblfish> Well because it is extreemly useful to have binary support, since otherwise one is extreemly limited.
18:08:39 <davidwood> cygri: HTTP already has features for handling binaries.  That's all we need.
18:08:59 <bblfish> Nasa wanting to publish pictures with metadata etc. The cost is very low. Atom supports it.
18:09:13 <davidwood> davidwood: HTTP doesn't specify what happens when you POST to an LDPC - that's our job.
18:09:31 <davidwood> SteveS: The proposed model is consistent.
18:09:48 <betehess> 1. we'll _eventually_ need binary support at the container level  2. meta resource is needed for *all* elements being added to the container, whether it's binary or regular LDPR
18:09:51 <davidwood> …The only special case is handling RDF.
18:10:41 <betehess> and a server can always refuse to handle binary data, just return an error, it would still be compliant
18:10:55 <nmihindu> +1 to SteveS
18:11:11 <davidwood> JohnArwe: Has seen a pattern of collections and their contained resources emerge in Tivoli REST interactions.  LDP defines this pattern.
18:11:22 <davidwood> …The client interaction becomes easier.
18:11:30 <SteveS> SteveS has joined #ldp.
18:12:03 <davidwood> cygri: The client interaction is even easier if clients know that containers only contain one content type.
18:12:56 <bblfish> what cygri says is odd. Clients only interact with resources: be they a container or an element.
18:13:07 <davidwood> …The server could construct two URIs (for binary and metadata).  Only the metadata URI needs to be in the container.
18:13:22 <bblfish> there is no reason why having different types of resources in a container is complex
18:13:22 <davidwood> Sandro: DELETEs would need to operate on both.
18:14:20 <davidwood> SteveS: You could convince existing clients that their existing create/delete behavior was broken.
18:14:21 <Zakim> -bblfish
18:15:38 <davidwood> cygri: I care that when I ask for Turtle and I get Turtle back.
18:15:54 <Zakim> +bblfish
18:16:16 <Arnaud> q?
18:16:44 <davidwood> cygri: If I have an LDPC and I get its list of members, I want to know in advance whether I can ask for Turtle.
18:16:46 <bblfish> well if you want to know before hand then you could add metadata to that entry in the container representation
18:16:59 <davidwood> +1 to bblfish
18:17:37 <bblfish> <> member> <jack>> . <jack>> mime "text/turtle" .
18:17:41 <betehess> I would expect the server to remember the mimetype that was used during the POST
18:18:12 <betehess> I wouldn't put a constraint on finding this information in the metadata
18:18:18 <Arnaud> zakim: who's here?
18:18:39 <krp> krp has joined #ldp.
18:18:47 <davidwood> Sandro: These are coin-flip decisions.  You could do it either way.
18:19:11 <davidwood> Arnaud: summarizes the debate
18:20:40 <sandro> strawpoll:   if you post an image to an LDPC:  (1) it becomes a member of the collection, (2) metadata about it becomes a member of the collection, (3) dont' do this, do something else.
18:21:14 <sandro> +1 +1 0
18:21:43 <SteveBattle> (+1,+1,0)
18:21:47 <davidwood> rgarcia: How does the server keep state?  It could be complex.
18:21:52 <Ashok> 1,0,0
18:21:56 <cygri> -1 +1 0 (the -1 assumes that the member has no turtle variant)
18:22:00 <rgarcia> s/rgarcia/mesteban/
18:22:22 <ericP> 010
18:22:24 <SteveS> +1, -1, -1
18:22:26 <rgarcia> +1, 0, 0
18:22:27 <cody> -1,-1,+1 (or I just still don't get it)
18:22:31 <JohnArwe> +1, -0.5, -1
18:22:34 <ericP> 0, +1, 0
18:22:34 <bblfish> mhh. I think it helps to write this out
18:22:38 <roger> 0, 0.5, 1
18:22:39 <betehess> 1, -1, -1
18:22:42 <TallTed> +1 -1 +1    a collection of (it, metadata) becomes "the" member
18:22:43 <mesteban> -1, +1, 0
18:22:45 <davidwood> +1, 0, 0 (the server should decide whether is wants to be complex)
18:22:50 <nmihindu> +1, +1, 0
18:22:53 <bblfish> One should write up both proposals I think.
18:22:56 <davidwood> Arnaud: We are all over the map.
18:23:12 <davidwood> Knives come out. People run.
18:23:15 <SteveS> s/+1, -1, -1/+1, -1, 0/
18:23:57 <davidwood> Arnaud: We need to discuss this, possibly with booze.
18:24:37 <sandro> cygri: some people say if I post to an LDPC exactly that thing should become a member of a container -vs- whatever I post, I want to make sure an LDPR was created
18:24:47 <davidwood> cygri: The disagreement is between POSTing a member to a container vs. POSTing a member to a container and being assured about getting some Turtle.
18:24:49 <rgarcia> q+
18:25:22 <davidwood> ericP: There is a third option if the binary goes into a different container.
18:25:50 <davidwood> …and the metadata is augmented with the location of the binary.
18:25:57 <mesteban> +1 to ericP
18:26:43 <Arnaud> ack rgarcia
18:27:11 <roger> +q
18:27:30 <davidwood> rgarcia: There are ways to ensure you only have one URI for the binary and its metadata (e.g. query string)
18:27:40 <SteveS> q+ I need 30 seconds
18:27:59 <mesteban> +1 to rgarcia, we could use a single URI and stick to content negotiation
18:28:00 <TallTed> restating my option (3) -- a new collection becomes a member of the existing collection, with "primary" member being the uploaded file, and "secondary" member being the metadata resource.  a GET on new collection delivers whichever member matches requested MIME, with preference to "primary"
18:28:00 <davidwood> q+ SteveBattle
18:28:13 <SteveS> q+
18:28:49 <Arnaud> ack roger
18:28:53 <SteveS> +q
18:29:54 <davidwood> roger: In the pagination discussion, we said that we wanted to have other types of collections (beyond LDPCs).
18:31:19 <davidwood> …we might want to have different types of resources (e.g. literals vs. URIs)
18:31:24 <Arnaud> ack steveb
18:31:40 <Arnaud> ack , Steves
18:31:48 <Arnaud> ack
18:31:53 <Arnaud> q=
18:32:01 <ericP> q?
18:32:04 <ericP> queue=
18:32:23 <davidwood> SteveS: Maybe we need Aggregate Containers that have special behavior.
18:33:43 <davidwood> Arnaud: Let's try to find an easy issue
18:34:00 <davidwood> cygri: Pagination needs a concrete proposal first.
18:34:25 <SteveS> I was saying that in my implementation, I might have a Container of type Aggregate that can enumerate the meta resources
18:34:41 <cygri> ISSUE-33?
18:34:42 <trackbot> ISSUE-33 -- Pagination for non-container resources -- open
18:34:42 <trackbot> http://www.w3.org/2012/ldp/track/issues/33
18:35:20 <davidwood> subTopic: ISSUE-33: Pagination for non-container resources
18:35:42 <davidwood> cygri: Summarizes the debate.
18:37:05 <davidwood> Sandro tries to draw the proposal. SteveS tries to take a picture of the whiteboard to upload it to his LDP server, but cygri wrestles him to the ground.
18:38:24 <davidwood> cygri: We want to be able to pull out properties that deal with like concepts and page them.
18:39:20 <davidwood> …Can the client specify the page size or ordering?  The one thing you really need is just a pointer from the resource to the first page and from each page to the next.  This is the minimal proposal.
18:40:33 <SteveBattle> q+
18:41:02 <davidwood> Sandro: Each very long resource could be broken into PropertyPages, which are identified with triples.
18:42:01 <SteveBattle> q-
18:42:17 <davidwood> cygri: Can you POST to a paged resource?  That seems orthogonal. You would probably POST or PATCH to the parent resource.
18:42:32 <SteveBattle> q+
18:42:45 <roger> +q
18:44:11 <davidwood> Arnaud: Someone asked about the order of pagination.  In the case of a container, this is the membership.  What can you paginate over if you don't have the concept of membership?
18:44:26 <Arnaud> ack steveb
18:44:39 <davidwood> SteveBattle: I don't think you should be forced to use aggregation.
18:44:55 <davidwood> SteveS: It could be as simple as a single triple.
18:45:07 <sandro> q?
18:45:08 <Arnaud> ack roger
18:45:15 <Ashok> q
18:45:20 <davidwood> q+ to ask whether PropertyPages would need to operate on a single predicate
18:45:28 <davidwood> q+ Ashok
18:45:32 <Ashok> q+
18:46:58 <davidwood> roger and JohnArwe discuss something related to container creation and how someone might add links to existing resources.
18:47:10 <SteveBattle> I agree that we shouldn't be forced into using (weak) aggregation just because we have a repeating relation.
18:47:29 <davidwood> roger: Examples in issue-34
18:47:32 <davidwood> issue-34?
18:47:32 <trackbot> ISSUE-34 -- Adding and removing arcs in weak aggregation -- closed
18:47:32 <trackbot> http://www.w3.org/2012/ldp/track/issues/34
18:47:49 <davidwood> JohnArwe: Those are supposed to be single-issue examples.
18:48:10 <Arnaud> ack david
18:48:10 <Zakim> davidwood, you wanted to ask whether PropertyPages would need to operate on a single predicate
18:48:50 <roger> +q
18:49:20 <davidwood> davidwood: Pagination might occur based only on length, as determined by the server or a client request.
18:50:01 <Arnaud> ack ashok
18:50:21 <davidwood> Arnaud: We want to ensure we don't solve use cases that aren't real.
18:51:37 <SteveBattle> What about paginating over rdf:_1, rdf:_2, rdf:_3, ... ? :)
18:51:41 <davidwood> Ashok: Stephen has properties and also thousands of friends.  A client might be on a small screen, so the server creates (transitory, virtual) PropertyPages.
18:51:59 <Arnaud> ack roger
18:52:05 <bblfish> I think betehess had a notion of having pagination being a list
18:52:05 <davidwood> …This means that PropertyPages can't be independently modified.
18:52:35 <davidwood> roger: If you have PropertyPages for Stephen's friends, that becomes a concept so you can POST to it.
18:52:37 <betehess>  rdf:list-s are prefect for the job, yes
18:53:06 <bblfish> <> pages> (<?page1> <?page2>> <?page3>> )
18:53:16 <SteveS> +q
18:53:17 <JohnArwe> +q
18:53:25 <betehess> using an rdf:list, you have ordering, and pagination becomes totally transparent
18:53:25 <Arnaud> ack steves
18:53:59 <bblfish> betehess: what does a paginated list look like? ( if you can write it out in IRC )
18:54:01 <davidwood> SteveS: The motivation of the current paging support was to narrow paging to containers, but the model is similar for other use cases.
18:54:25 <davidwood> …There is already a link: header for paging.
18:55:08 <betehess> bblfish, just a regular list, but when you encounter a URL instead of a blank node, you know that you have to follow this url to find the rest of the list
18:55:50 <Arnaud> ack john
18:55:57 <betehess> a Linked Data client should be prepared to read that kind of data anyway, and it's already standardized, nothing new here
18:55:57 <davidwood> Arnaud: This could be simplified by recognizing that there are use cases for paging, so we might want to generalize the existing solution for containers.
18:56:28 <davidwood> JohnArwe: The only controversial part is to make that the *only* way to accomplish the use cases.
18:56:44 <bblfish> Arnaud's suggestion seems generally a good idea. If pagination works well it should work for any resource.
18:57:00 <davidwood> …not a fan of MUST NOT restrictions unless they are very well understood.
18:57:28 <davidwood> roger: Anything that smells like reification becomes immediately controversial.
18:57:47 <JohnArwe> @roger: not the kind of controversy I thought you meant
18:57:59 <cygri> q+
18:58:13 <Arnaud> ack cygri
18:58:41 <davidwood> PROPOSAL: Close ISSUE-33 by saying that the same pagination mechanism defined for LDPCs be adopted for LDPRs.
18:58:47 <sandro> cygri: I'm okay with this, as long as we can improve the existing mechanism
18:58:52 <cygri> +1
18:58:52 <sandro> Arnaud: yes, we can.
18:58:54 <SteveS> +1
18:58:54 <SteveBattle> +1
18:58:55 <bblfish> +1
18:58:57 <rgarcia> +1
18:59:00 <Ashok> +1
18:59:00 <cody> +1
18:59:03 <davidwood> +0.5
18:59:07 <sandro> +1
18:59:07 <mesteban> +0.5
18:59:07 <cygri> ISSUE-18?
18:59:07 <trackbot> ISSUE-18 -- container membership and robust pagination -- open
18:59:07 <trackbot> http://www.w3.org/2012/ldp/track/issues/18
18:59:24 <TallTed> +1
18:59:25 <JohnArwe> +1
18:59:26 <nmihindu> +1
18:59:29 <betehess> 0
19:00:05 <Arnaud> RESOLVED: Close ISSUE-33 by saying that the same pagination mechanism defined for LDPCs be adopted for LDPRs.
19:00:11 <davidwood>  ISSUE-33: Pagination for non-container resources
19:00:11 <trackbot> Notes added to ISSUE-33 Pagination for non-container resources.
19:00:14 <davidwood> issue-33
19:00:14 <trackbot> ISSUE-33 -- Pagination for non-container resources -- open
19:00:14 <trackbot> http://www.w3.org/2012/ldp/track/issues/33
19:00:32 <davidwood> roger: This decision is being rushed.
19:00:51 <davidwood> CLOSE ISSUE-33
19:00:52 <trackbot> Closed ISSUE-33 Pagination for non-container resources.
19:00:55 <davidwood> link?
19:01:12 <sandro> rrsagent, pointer?
19:01:33 <roger> -1
19:01:41 <SteveBattle> Aggregations should only be used to represent mereology
19:02:53 <RRSAgent> RRSAgent has joined #ldp.
19:02:53 <RRSAgent> logging to http://www.w3.org/2013/03/14-ldp-irc
19:03:03 <davidwood> Arnaud and roger discuss the opportunity to reopen this issue if roger remains unhappy with it after the editors update the draft.
19:03:41 <JohnArwe> FWIW, wrt pagesize and the existing link headers I don't see anything promising in the link relations registry http://www.iana.org/assignments/link-relations/link-relations.xml ... I see first, last, next, prev all of which appear to have come from RFC 5005 and those are now registered via RFC 5988.
19:04:47 <sandro> roger: My concern is that Container pagination might not actually work for Resource Pagination, despite SteveS claiming it does.
19:05:42 <SteveS> This proposal was originally discussed on Feb 11th btw http://www.w3.org/2012/ldp/meeting/2013-02-11#Issue__2d_33_Pagination_for_non__2d_container_resources
19:06:11 <sandro> davidwood: summarize objection process
19:07:18 <davidwood> Arnaud: We can spend some time after hours and also tomorrow to see if we need to reopen ISSUE-33.
19:07:43 <davidwood> WG breaks for 25 minutes
19:09:21 <rgarcia> rgarcia has left #ldp
19:14:37 <krp> krp has left #ldp
19:19:22 <SteveS> SteveS has left #ldp
19:33:50 <cygri> scribe: cygri
19:33:54 <SteveS> SteveS has joined #ldp.
19:34:16 <rgarcia> rgarcia has joined #ldp.
19:34:36 <Arnaud> "must-haves": 15, 17, 32, 37, 38
19:34:51 <cygri> Arnaud: Let's get back to our list of high-priority issues.
19:35:16 <cygri> ISSUE-32?
19:35:16 <trackbot> ISSUE-32 -- How can clients discover that a resource is an LDPR or LDPC, and what features are supported? -- open
19:35:16 <trackbot> http://www.w3.org/2012/ldp/track/issues/32
19:35:26 <cygri> ISSUE-37?
19:35:26 <trackbot> ISSUE-37 -- What is the LDP data model and the LDP interaction model? -- open
19:35:26 <trackbot> http://www.w3.org/2012/ldp/track/issues/37
19:35:30 <cygri> ISSUE-38?
19:35:30 <trackbot> ISSUE-38 -- filtered representations and inlining -- open
19:35:30 <trackbot> http://www.w3.org/2012/ldp/track/issues/38
19:36:03 <cygri> subtopic: ISSUE-32: Discovering LDPRs, LDPCs, and their supported features
19:36:33 <JohnArwe> http://www.w3.org/2012/ldp/wiki/ISSUE-32
19:37:37 <cygri> John's wiki page: http://www.w3.org/2012/ldp/wiki/ISSUE-32#Affordances
19:38:11 <SteveBattle> If you try a GET, and get back RDF that says it's an LDPR or LDPC doesn't that solve the first part of the issue?
19:38:23 <cygri> q+
19:38:38 <Arnaud> ack cygri
19:38:48 <SteveS> q+
19:39:53 <Arnaud> cygri: restates the need for discovery in REST
19:40:44 <Arnaud> cygri: one possibility is to add triples to express what can be done
19:41:01 <Arnaud> cygri: another is to use the option method
19:41:26 <Arnaud> cygri: erik said you should use mediatypes
19:41:49 <Arnaud> cygri: there are different ways but it's good to have a way to find out before trying
19:41:52 <cygri> sandro: I like putting this information into the RDF
19:42:02 <cygri> Ashok: what if it's an image?
19:42:07 <cygri> sandro: Put it into the metadata.
19:42:30 <cygri> JohnArwe: What if different members have different interaction capabilities?
19:42:47 <cygri> sandro: You learn by GETting each resource.
19:43:34 <cygri> davidwood: What we do [in Callimachus], you can start at the top, discover containers, then members, and discover everything on the server.
19:43:42 <cygri> ... We don't quite have that in LDP at the moment.
19:43:47 <SteveBattle> q+
19:43:48 <cygri> ... Discoverability is a good thing.
19:44:00 <Arnaud> ack steves
19:44:06 <bblfish> bblfish has left #ldp
19:44:28 <bblfish> bblfish has joined #ldp.
19:44:40 <cygri> SteveS: Putting this in RDF, HEAD, headers, etc seem all fine.
19:44:48 <cygri> ... Should use HTTP-level options where possible
19:44:52 <JohnArwe> q+
19:45:05 <Arnaud> ack steveb
19:45:30 <cygri> SteveBattle: If this info is in RDF, then we need to define it in the LDP ontology.
19:45:42 <cygri> Arnaud: Does the LDP ontology become part of the spec?
19:45:46 <cygri> JohnArwe: Yes.
19:45:55 <Arnaud> ack john
19:46:00 <cygri> Arnaud: Can we go back to John's wiki page?
19:46:01 <cygri> http://www.w3.org/2012/ldp/wiki/ISSUE-32#Affordances
19:46:48 <cygri> JohnArwe: I went through the spec, trying to find everything that a client might possibly want to introspect.
19:47:09 <cygri> ... If the spec says how to discover optional features, then I put it in.
19:47:48 <cygri> ... There's also POWDER as another way of discovering things.
19:47:54 <nmihindu> nmihindu_ has joined #ldp.
19:48:13 <cygri> ... The more resources your app is dealing with, the more resources it would need to introspect.
19:48:43 <nmihindu> nmihindu has left #ldp
19:48:44 <cygri> ... POWDER allows making assertions about sets of resources. Scalable
19:49:19 <cygri> davidwood: The driving use case for PICS (?), POWDER's preprocessor, was porn
19:49:39 <cygri> ... State whether a resource is NSFW
19:50:02 <cygri> ... The porn guys liked it, but the browser guys wouldn't implement it
19:50:44 <cygri> ... POWDER a successor. Lacks a strong use case. The POWDER guys would be happy if you find one!
19:52:33 <cygri> SteveS: Someone should take an action to make another pass over John's wiki page, propose terms etc
19:52:56 <cygri> Arnaud: Is this the direction the group needs to go in?
19:53:05 <cygri> sandro: Do clients benefit from all of these things?
19:53:05 <cygri> q+
19:53:20 <Arnaud> s/needs/wants/
19:53:42 <cygri> ... In my mind, you have general-purpose and domain-specific LDP servers
19:53:58 <cygri> ... Will they implement everything, or the minimum they can get away with?
19:54:08 <krp> krp has joined #ldp.
19:54:11 <cygri> JohnArwe: Not just *one* class of domain-specific LDP servers
19:54:12 <Arnaud> ack cygri
19:55:49 <Arnaud> cygri: discoverability is especially important for write operations
19:56:43 <JohnArwe> q+
19:57:07 <nmihindu>_ is now known as nmihindu
19:57:34 <Arnaud> ack john
19:57:40 <JohnArwe> q-
19:57:47 <cygri> SteveS: Capabilities and permissions can be dynamic. PUT doesn't show up as allowed method if you don't have the permission
19:58:32 <cygri> sandro: POWDER says, "all resources with this URI template have this property"
19:58:57 <cygri> JohnArwe: So we'd have the same ontology, but a different way of saying it
19:58:58 <cygri> q+
19:59:44 <SteveS> q+
20:00:07 <cygri> JohnArwe: We may not have to do anything different about POWDER. Just define the ontology and mention that POWDER exists as an option
20:00:16 <cygri> q-
20:00:36 <cygri> sandro: The hard part is clustering of features into labelled profiles
20:00:45 <Arnaud> ack steves
20:01:13 <cygri> JohnArwe: I could take an action to define the ontology
20:01:37 <cygri> SteveS: me too
20:02:51 <Arnaud> action: johnarwe to come up with an ontology proposal for discovery
20:02:51 <trackbot> Error finding 'johnarwe'. You can review and register nicknames at <http>://www.w3.org/2012/ldp/track/users>.
20:03:35 <cygri> JohnArwe: I assume we could put a version of this table into one of the extra documents
20:03:48 <Arnaud> action: john to come up with an ontology proposal for discovery
20:03:48 <trackbot> Created ACTION-51 - Come up with an ontology proposal for discovery [on John Arwe - due 2013-03-21].
20:05:29 <cygri> JohnArwe: So we leave the issue open.
20:05:36 <cygri> ACTION-51?
20:05:36 <trackbot> ACTION-51 -- John Arwe to come up with an ontology proposal for discovery -- due 2013-03-21 -- OPEN
20:05:36 <trackbot> http://www.w3.org/2012/ldp/track/actions/51
20:05:39 <nmihindu> JohnArwe, this might be interesting to look for binary resources link header too http://www.w3.org/TR/powder-dr/#httplink
20:05:52 <bblfish> Its late here. I'll join back tomorrow I think.
20:06:00 <Arnaud> "must-haves": 15, 17, 32, 37, 38
20:06:05 <cygri> ISSUE-37?
20:06:05 <trackbot> ISSUE-37 -- What is the LDP data model and the LDP interaction model? -- open
20:06:05 <trackbot> http://www.w3.org/2012/ldp/track/issues/37
20:06:08 <cygri> ISSUE-38?
20:06:08 <trackbot> ISSUE-38 -- filtered representations and inlining -- open
20:06:08 <trackbot> http://www.w3.org/2012/ldp/track/issues/38
20:06:25 <cygri> Arnaud: I don't want to talk about ISSUE-37.
20:06:51 <cygri> subtopic: ISSUE-38: Filtered representations and inlining
20:06:56 <bblfish> bblfish has left #ldp
20:07:15 <Zakim> -bblfish
20:07:45 <cygri> Arnaud: The spec provides a mechanism to specify non-member properties on a container.
20:08:05 <cygri> ... From what I remember, Roger felt this is limiting
20:08:23 <cygri> roger: The number of non-member properties could be massive.
20:08:41 <cygri> q+
20:09:01 <Arnaud> ack cygri
20:09:53 <SteveBattle> The corresponding use-case: http://www.w3.org/TR/2013/WD-ldp-ucr-20130131/#use-case-filter-resource-description
20:11:04 <JohnArwe> q+
20:13:20 <SteveS> q+
20:13:52 <cygri> cygri: (1) why do we call out the possibility of including extra triples for LDPC members but not for other resources? (2) would be nice if we could flag that the included extra triples are in fact all the triples the server knows about the member
20:13:59 <Arnaud> ack john
20:14:39 <cygri> JohnArwe: This feature is mentioned for containers because that's where we saw it coming up in our products. No intention to be limiting. The server can always include extra triples.
20:16:08 <cygri> ... Such a flag might not give you complete information anyway; etag headers etc.
20:16:14 <Arnaud> ack steves
20:16:45 <cygri> SteveS: Other resolved issues may already answer some of this.
20:17:18 <cygri> ... For example, next page being rdf:nil could indicate there's no more triples
20:18:20 <cygri> ... We support filtering and inlining in some of our implementations and other specs. We see the need, and it works. But speccing this is difficult.
20:18:45 <cygri> ... Given the timeline, I fear we might not be able to get there in such a short period of time
20:18:53 <cygri> Arnaud: We'd need a proposal.
20:19:18 <cygri> ... On the mailing list it was asked: How powerful do you want this system to be?
20:19:37 <cygri> ... You could go all the way to an all-powerful query system.
20:19:55 <SteveS> For references, here's how I've don't "inline" of resources http://open-services.net/bin/view/Main/OslcCoreSpecification#Selective_Property_Values
20:19:56 <cygri> ... Without a specific use case and proposal, it will be difficult to make progress
20:20:33 <cygri> ... Roger, Richard, do you want to come up with a specific proposal?
20:20:40 <SteveS> Here's the "filter" language (build up query URL) http://open-services.net/bin/view/Main/OslcCoreSpecification#Query_Capabilities
20:21:06 <rgarcia> q+
20:21:12 <cygri> ... Can we agree to postpone the issue?
20:21:18 <Arnaud> ack rgarcia
20:21:56 <cygri> rgarcia: Flag this as something that's useful, out of scope now, but can be done later
20:22:12 <cygri> Arnaud: I'd like to talk about possible future working group
20:22:29 <cygri> ... Good first step for LDP2-WG would be a draft charter with a feature list
20:23:16 <cygri> ... Perhaps we should have a wiki page with 2.0 features
20:23:29 <cygri> davidwood: Mark issues as postponed
20:23:42 <mesteban> +1 to Arnaud
20:24:31 <cygri> [discussion of new WG vs. rechartering]
20:27:33 <Arnaud> Proposed: Close Issue-38, putting this on the wish list (to be created) for LDP++
20:28:07 <cody> +1
20:28:09 <JohnArwe> +1
20:28:10 <TallTed> +1
20:28:12 <krp> +1
20:28:13 <SteveBattle> 0
20:28:16 <davidwood> 0
20:28:16 <rgarcia> +1
20:28:17 <mesteban> +1
20:28:18 <SteveS> +1
20:28:19 <nmihindu> +1
20:28:31 <roger> +1 (I still don't like non-member-properties )
20:28:35 <cygri> +1 but I will raise a new issue for the "are members completely inlined?" flag
20:29:20 <Arnaud> Resolved: Close Issue-38, putting this on the wish list (to be created) for LDP++
20:29:21 <sandro> +1
20:30:36 <Arnaud> action: roger to create a wish list wiki page with issue-38
20:30:37 <trackbot> Created ACTION-52 - Create a wish list wiki page with issue-38 [on Roger Menday - due 2013-03-21].
20:31:38 <cygri> ISSUE-37?
20:31:38 <trackbot> ISSUE-37 -- What is the LDP data model and the LDP interaction model? -- open
20:31:38 <trackbot> http://www.w3.org/2012/ldp/track/issues/37
20:31:52 <cygri> subtopic: ISSUE-37: What is the LDP data model and the LDP interaction model?
20:31:58 <Arnaud> "must-haves": 15, 17, 32, 37
20:32:00 <cygri> Arnaud: Do we really want to talk about this?
20:32:58 <davidwood> q+ to discuss the spec intro section
20:33:26 <cygri> ... Erik and I felt that nailing down the model would clarify lots of things, expose unspoken assumptions regarding what the spec is about, and so on
20:33:51 <cygri> ... There was lots of effort poured into this, and it didn't seem like we were converging
20:34:28 <cygri> ... So maybe we need to keep working on the details of the specification, create a test suite, and identify holes and misinterpretations that way
20:34:35 <SteveS> q+
20:35:16 <Arnaud> ack david
20:35:16 <Zakim> davidwood, you wanted to discuss the spec intro section
20:35:29 <cygri> davidwood: I have an action to review the UC&R document. I've begun that process.
20:35:46 <cygri> ... The core spec does not have a good introduction.
20:36:30 <cygri> ... The UC&R intro is pretty good language, pretty clear.
20:36:42 <roger> roger has left #ldp
20:37:18 <cygri> ... I propose that the UC&R intro should be lifted into the core spec.
20:37:53 <cygri> SteveBattle: My intro was largely taken from the original use case submission.
20:38:24 <roger> roger has joined #ldp.
20:38:36 <SteveBattle> q+
20:38:41 <Arnaud> ack steves
20:38:53 <cygri> davidwood: People will start with the REC spec, therefore it should have a good introduction.
20:39:13 <SteveBattle> q-
20:39:22 <cygri> SteveS: I recommend against reading the ISSUE-37 wiki page. It's confusing.
20:40:28 <cygri> ... I'm not sure what the proposal is. What part is intended to be replaced?
20:40:58 <cygri> Arnaud: I think we all agree that a new introduction/motivation for the spc would be good.
20:41:03 <cygri> s/spc/spec/
20:41:38 <cygri> davidwood: Explain the model concisely in the introduction.
20:42:17 <cygri> Ashok: I thought we had pretty good agreement regarding the model.
20:43:06 <cygri> ... You should talk about it to see if we have agreement.
20:43:41 <cygri> SteveS: People are not disagreeing with the model. They are disagreeing with my way of describing the model.
20:43:49 <cygri> Ashok: I'm not sure that it's just editorial.
20:44:25 <roger> i  disagree with some aspects of the model :)
20:45:51 <cygri> [discussion on how to make progress]
20:49:09 <Arnaud> action: steves to draft an introduction describing the LDP model for the WG to review
20:49:09 <trackbot> Created ACTION-53 - Draft an introduction describing the LDP model for the WG to review [on Steve Speicher - due 2013-03-21].
20:49:59 <cygri> roger: I think that core LDP should be doing manipulation of linked data. We can layer the container thing on top of that.
20:50:11 <cygri> ... It's weird that we introduce the notion of containers at the use case level.
20:50:16 <SteveBattle> q+
20:50:37 <cygri> ... It's like we decided the architecture before the use cases.
20:51:05 <cygri> ... I don't think containers really should be core.
20:51:30 <SteveS> q+
20:52:03 <cygri> ... The nested-container use case might be interesting to some here, but LDP has potentially a much bigger audience, around services
20:52:15 <krp> krp has left #ldp
20:52:31 <cygri> q+
20:53:09 <cygri> Arnaud: The genesis of this group was to define common usage patterns for linked data.
20:53:22 <cygri> ... So that people don't reinvent these things again and again.
20:53:45 <krp> krp has joined #ldp.
20:53:52 <cygri> davidwood: We have a number of different implementations that need a container-like thing.
20:54:33 <cygri> roger: In our work we came up with containers as well. We called them progenitors and progeny.
20:54:58 <cygri> ... Besides this strong ancestry notion, we also want to have links across.
20:55:10 <Arnaud> ack steveb
20:55:17 <cygri> ... In LDP we only handle that via PATCH.
20:55:43 <cygri> SteveBattle: Containers came up in many use cases. It's how people want to use this.
20:55:46 <Arnaud> ack steves
20:55:59 <SteveBattle> s/use cases/user stories/
20:56:08 <cygri> SteveS: Roger, you use the word "service" a lot. Not sure if you mean the "shopping cart" sort of service.
20:56:22 <cygri> ... I see that as a very different architecture from what linked data is
20:56:43 <cygri> ... In linked data you'd have a shopping cart resource that can be manipulated via LDP
20:57:26 <cygri> roger: You can do a brilliant shopping cart with linked data and REST
20:57:43 <Arnaud> ack cygri
20:58:44 <JohnArwe> cygri: would like to see output be what spec promises = how to update linked data
20:59:15 <roger> cygri: wants LDP to add something to the 4 axioms of Linked Data
20:59:36 <JohnArwe> ...container design, nested containers, posting to create new resources is all kind of orthogonal to "how to update linked data"
21:00:20 <roger> cygri: thinks we can tweak the container concept a bit more to more towards this objective
21:00:26 <JohnArwe> ...we've tweaked it to allow more of the cross-resource linking, but I don't like the whole choice of terminology; aggr, composition, etc never existed in LD before, and they don't help me to do updates on LD
#21:01:49 <bhyland> bhyland has left #ldp
21:02:01 <JohnArwe> arnaud plays back cygri's remarks to verify understanding
21:02:38 <cody> q+
21:02:40 <roger> q+
21:03:51 <Arnaud> ack cody
21:04:30 <cygri> cody: Is a container thought of as an LDP-specific object, or can it also be a domain object?
21:05:01 <Zakim> disconnecting the lone participant, WG-meeting, in SW_LDP(F2F)8:30AM
21:05:02 <Zakim> SW_LDP(F2F)8:30AM has ended
21:05:02 <Zakim> Attendees were WG-meeting, bblfish
21:05:14 <Arnaud> ack roger
21:05:16 <cygri> JohnArwe: As long as it has the right interface, it can act as both
21:05:55 <cygri> roger: I appreciate that there's the container pattern.
21:06:32 <cygri> ... But if what we're doing is adding the fifth principle of linked data, then it should work for all properties.
21:06:54 <davidwood> q+
21:07:09 <cygri> ... not just container membmership property
21:07:39 <cygri> Arnaud: There's a tradeoff between something very minimalist and widely applicable, and something more specific
21:07:54 <cygri> ... You could argue that some container stuff should be removed to a separate spec
21:08:08 <cygri> ... You could also argue that the discovery bit should be a separate package
21:08:16 <cygri> ... Specs can define conformance levels
21:08:26 <cygri> ... Just throwing this out as food for thought
21:08:31 <Arnaud> ack david
21:08:52 <cygri> davidwood: To me a container is just some RDF that the server knows how to act upon
21:09:13 <cygri> topic: Planning for tomorrow
21:10:17 <cygri> Arnaud: Next F2F ... More pending issues ... pagination ... patch
21:10:33 <cygri> ... We'll close at 4pm tomorrow
21:10:58 <TallTed> +1 davidwood (which is why I disagree with so much special-case-handling for composition vs aggregation -- this is just how the server acts upon that RDF)
21:10:58 <cygri> ... If you care about specific issues, you have to make proposals.
21:11:22 <cygri> ... There'll be a time when we'll just close issues because we don't have any proposals for them
21:11:30 <cygri> q+
21:12:06 <cody> I'm leaving at about 3:00 tomorrow (flight)
21:12:15 <davidwood> TallTed, right!
21:12:35 <Arnaud> ack cygri
21:12:43 <roger> to me, LDP is just some RDF that a client knows how to act upon
21:13:57 <davidwood> roger, that may be the most succinct description of our disagreements I have yet heard. Maybe we should discuss this in more detail.
21:14:29 <JohnArwe> I'm quite willing to continue this discussion over dinner tonight
21:14:43 <JohnArwe> (yes, I enjoy pain)
21:20:04 <Arnaud> meeting adjourned
21:20:04 <davidwood> davidwood has left #ldp
21:21:18 <SteveS> SteveS has left #ldp
21:23:24 <rgarcia> rgarcia has left #ldp
21:24:40 <mesteban> mesteban has left #ldp
21:29:40 <nmihindu> nmihindu has left #ldp
21:37:05 <cygri> cygri has left #ldp
21:41:08 <Ashok> Ashok has left #ldp
# SPECIAL MARKER FOR CHATSYNC.  DO NOT EDIT THIS LINE OR BELOW.  SRCLINESUSED=00000269