Chatlog 2010-06-24

From RDFa Working Group Wiki
Jump to: navigation, search

See CommonScribe Control Panel, original RRSAgent log and preview nicely formatted version.

13:49:57 <RRSAgent> RRSAgent has joined #rdfa
13:49:57 <RRSAgent> logging to
13:51:13 <manu> trackbot, prepare telecon
13:51:15 <trackbot> RRSAgent, make logs world
13:51:17 <trackbot> Zakim, this will be 7332
13:51:17 <Zakim> ok, trackbot; I see SW_RDFa()10:00AM scheduled to start in 9 minutes
13:51:18 <trackbot> Meeting: RDFa Working Group Teleconference
13:51:18 <trackbot> Date: 24 June 2010
13:51:25 <manu> Chair: Manu
13:51:33 <manu> Agenda:
13:52:19 <ivan> ivan has joined #rdfa
13:52:30 <manu> Present: Manu, Ivan, Toby, ShaneM, Benjamin
13:52:34 <manu> Regrets: Markus
13:55:52 <Benjamin> Benjamin has joined #rdfa
13:59:26 <manu> zakim, code?
13:59:26 <Zakim> the conference code is 7332 (tel:+1.617.761.6200 tel:+ tel:+44.117.370.6152), manu
13:59:50 <Zakim> SW_RDFa()10:00AM has now started
13:59:57 <Zakim> +[IPcaller]
13:59:57 <manu> zakim, I am IPCaller
13:59:58 <Zakim> ok, manu, I now associate you with [IPcaller]
14:00:16 <ivan> zakim, dial ivan-voip
14:00:16 <Zakim> ok, ivan; the call is being made
14:00:17 <Zakim> +Ivan
14:00:29 <Zakim> + +
14:01:24 <Benjamin> zakim, + is Benjamin
14:01:24 <Zakim> +Benjamin; got it
14:01:41 <Zakim> + +1.612.217.aabb
14:01:48 <ShaneM> ShaneM has joined #rdfa
14:02:31 <manu> zakim, who is noisy?
14:02:42 <Zakim> manu, listening for 10 seconds I could not identify any sounds
14:03:30 <manu> Changes that Facebook agreed to:
14:03:39 <manu> zakim, who is noisy?
14:03:50 <Zakim> manu, listening for 10 seconds I heard sound from the following: [IPcaller] (22%), +1.612.217.aabb (25%)
14:03:59 <ShaneM> zakim, aabb is ShaneM
14:03:59 <Zakim> +ShaneM; got it
14:04:17 <manu> zakim, who is on the phone?
14:04:17 <Zakim> On the phone I see [IPcaller], Ivan, Benjamin, ShaneM
14:06:41 <manu> Scribe: Benjamin
14:06:47 <manu> scribenick: Benjamin
14:08:41 <manu> Topic: ISSUE-26: Error Reporting Mechanism
14:08:48 <ivan> q+
14:08:51 <Benjamin>
14:09:23 <manu> ack ivan
14:10:13 <Benjamin> manu: Two proposals an event mechanism (in the RDFa API) and a second to put error triples in a named RDF graph (in RDFa Core)
14:10:39 <Benjamin> ivan: It's difficult to discuss this without Mark
14:11:48 <Benjamin> ... Mark was not fond of putting error triples into the default graph
14:12:49 <Benjamin> ivan: Using a named graph as target for error triples needs to support named graphs in tools like the distiller.
14:13:20 <tinkster> tinkster has joined #rdfa
14:15:40 <Benjamin> manu: Callback functions can be used hook for dealing with warnings and errors in the RDFa API.
14:16:12 <ShaneM> q+ to ask about graphs and opaque processing
14:16:18 <manu> ack shanem
14:16:18 <Zakim> ShaneM, you wanted to ask about graphs and opaque processing
14:16:19 <Benjamin> ... otherwise parsers and tools may access these triples in an error graph
14:17:08 <Benjamin> ShaneM: A service like the distiller returns triples from a URL. 
14:17:24 <Benjamin> ... there is no way to distinguish between different graphs
14:17:34 <manu> q+
14:18:13 <manu> ack IPcaller
14:18:34 <Benjamin> ... It has to provide additional paramaters to let users extract just the error triples
14:18:38 <ShaneM> zakim, ipcaller is manu
14:18:38 <Zakim> +manu; got it
14:19:11 <ivan> q+
14:19:26 <ivan> ack [[IPcaller]
14:19:42 <Benjamin> manu: Either you are using a programming language to consume RDF triples from a page. Then you can access some error graphs as named graph.
14:20:04 <manu> ack ipcaller
14:21:18 <manu> Manu: We can identify graphs via the RDFa Processor API = parse(foo, graph="default)" or ""
14:21:19 <Benjamin> ivan: Everything is doable. But why is it so important to put the error triples in their own graph.
14:22:12 <Benjamin> ... We can store it in the default graph and just classify them as error triples.
14:23:15 <Benjamin> manu: We should keep page triples separate from other kind of triples
14:23:51 <ivan> q+
14:24:46 <ShaneM> q+ to discuss the downside
14:24:47 <manu> ack ivan
14:24:54 <Benjamin> ... otherwise it is hard to decide whether a triple came from the processor or from the original page
14:26:03 <Benjamin> ivan: If we can add error handling to the API level, I am fine with it. But I think if we add error graphs in RDFa we also should define a GET interface to retrieve these.
14:26:53 <manu> ack shanem
14:26:53 <Zakim> ShaneM, you wanted to discuss the downside
14:27:02 <Benjamin> ... it will increase the complexity
14:27:39 <Benjamin> ShaneM: RDFa depends on RDF normatively. But RDF does not define named graphs.
14:29:17 <ivan> q+
14:29:28 <manu> ack ivan
14:29:49 <Zakim> -manu
14:29:54 <Benjamin> manu: We should not explain entire Named Graph concepts in our spec.
14:30:22 <Zakim> +[IPcaller]
14:30:45 <ShaneM> zakim, who is here?
14:30:45 <Zakim> On the phone I see Ivan, Benjamin, ShaneM, [IPcaller]
14:30:46 <Zakim> On IRC I see tinkster, ShaneM, Benjamin, ivan, RRSAgent, Zakim, manu, csarven, trackbot
14:30:53 <Benjamin> ShaneM: We really can't handle the problem. But it's there.
14:31:57 <ivan> about="" rel="xhv:stylesheet" resource="blablab"
14:32:32 <Benjamin> ShaneM: RDFa core says that a processor should not store a triple in the default graph if it is not from the document.
14:34:27 <Benjamin> ivan: It's the first time we are talking about adding triples to the default graphs that do not come from the document.
14:35:22 <manu> Toby: error reporting should belong entirely to the API. non-RDFa-API processors may want to include some error logging/reporting mechanism, but they should choose a mechanism appropriate for their environment - we shouldn't foist one onto them. 
14:35:58 <ivan> q+
14:36:02 <manu> ack ivan
14:36:28 <manu> Manu: I disagree, Toby - I'd really like to be able to expose warnings and errors from librdfa, if we depend on the RDFa API, I can't do that in a standard way.
14:37:08 <Benjamin> ivan: RDFa applications often extract just the triples and do not need the RDFa API.
14:39:17 <ShaneM> note that SPARQL query has named graphs, we're not breaking new ground here -
14:41:47 <Benjamin> manu: Each processor should have a parameter to let users retrieve non-error triples or error triples.
14:42:21 <Benjamin> ShaneM: On a dynamic page you may not want to do two requests.
14:43:19 <ivan> q+
14:43:24 <Benjamin> manu: RDFa Core: If a processor throws any errors, these are stored inside a processor graph
14:43:28 <Benjamin> ... all other triples are stored in the default graph.
14:43:35 <Benjamin> ... we specify language in RDFa Core that states that you can say that you want triples via a "graph" parameter to the parser. You would mention the "processor" graph, the "default" graph or "all" graphs for programmatic-based languages like Python, PHP, Perl and C. This same parameter could be passed to URL-based services, so one would add a query parameter graph=processor to get all triples from the processor graph, graph=default to get all triples from the default graph, or graph=all to get a combined list of triples from all graphs.
14:43:45 <Benjamin> manu: RDFa API: We institute an event-based mechanism by allowing the registration of a callback that is called whenever items are added to a particular graph, the graph can be identified as "default" or "processor" or "all". We may also want the ability to retrieve a Data Store based on name "default", "processor" or "all" - these stores could hang off of the DocumentData object. For example:,, and
14:43:59 <Benjamin> General agreement on moving forward with this approach.
14:44:13 <manu> zakim, mute shanem
14:44:13 <Zakim> ShaneM should now be muted
14:45:38 <manu> ACTION: Manu to write up RDFa Processor warning/error reporting language and send to mailing list.
14:45:38 <trackbot> Created ACTION-32 - Write up RDFa Processor warning/error reporting language and send to mailing list. [on Manu Sporny - due 2010-07-01].
14:46:02 <manu> ACTION: Ivan to specify error/warning triple vocabulary and send to mailing list.
14:46:02 <trackbot> Created ACTION-33 - Specify error/warning triple vocabulary and send to mailing list. [on Ivan Herman - due 2010-07-01].