Chatlog 2010-11-18

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

14:55:54 <RRSAgent> RRSAgent has joined #rdfa
14:55:54 <RRSAgent> logging to http://www.w3.org/2010/11/18-rdfa-irc
14:55:56 <trackbot> RRSAgent, make logs world
14:55:56 <Zakim> Zakim has joined #rdfa
14:55:58 <trackbot> Zakim, this will be 7332
14:55:58 <Zakim> ok, trackbot; I see SW_RDFa()10:00AM scheduled to start in 5 minutes
14:55:59 <trackbot> Meeting: RDFa Working Group Teleconference
14:55:59 <trackbot> Date: 18 November 2010
14:56:02 <manu> Agenda: http://lists.w3.org/Archives/Public/public-rdfa-wg/2010Nov/0101.html
14:56:09 <manu> Chair: Manu
14:56:58 <manu> Present: Ivan, Nathan, Steven, Manu, ShaneM, Benjamin, MarkB
14:58:24 <ivan> zakim, dial ivan-voip
14:58:24 <Zakim> ok, ivan; the call is being made
14:58:25 <Zakim> SW_RDFa()10:00AM has now started
14:58:28 <Zakim> +Ivan
14:59:44 <markbirbeck> markbirbeck has joined #rdfa
15:00:01 <markbirbeck> zakim, who is here?
15:00:01 <Zakim> On the phone I see Ivan
15:00:03 <Zakim> On IRC I see markbirbeck, Zakim, RRSAgent, manu, Steven, ivan, Nathan, trackbot
15:00:31 <Zakim> +manu
15:01:33 <markbirbeck> Manu...I'm at a two-day open data camp: http://blog.okfn.org/2010/08/13/open-government-data-camp-2010-18-19th-november-2010/ I thought I'd be able to find a quiet spot to join the call, but it's not possible. I'll hang out on IRC as much as I can, in case you need any extra votes. :)
15:02:46 <markbirbeck> (I.e., I know there are some issues that you wanted to close sooner rather than later.)
15:02:46 <Zakim> +??P34
15:02:56 <Nathan> Zakim, I am ?
15:02:56 <Zakim> +Nathan; got it
15:03:29 <Benjamin> Benjamin has joined #rdfa
15:04:02 <Zakim> + +1.612.217.aaaa
15:04:10 <Steven> zakim, dial steven-617
15:04:10 <Zakim> ok, Steven; the call is being made
15:04:11 <Zakim> +Steven
15:05:30 <manu> zakim, who is on the call?
15:05:30 <Zakim> On the phone I see Ivan, manu, Nathan, +1.612.217.aaaa, Steven
15:05:48 <Zakim> + +63.12.057.5aabb
15:05:58 <Steven> zakim, aaaa is Shane
15:05:58 <Zakim> +Shane; got it
15:06:21 <manu> scribe: Steven
15:06:22 <Benjamin> zakim, aabb is Benjamin
15:06:22 <Zakim> +Benjamin; got it
15:06:26 <manu> scribenick: Steven
15:06:35 <manu> Agenda: http://lists.w3.org/Archives/Public/public-rdfa-wg/2010Nov/0101.html
15:06:44 <ShaneM> ShaneM has joined #rdfa
15:06:47 <Steven> Scribe: Steven
15:06:59 <ShaneM> is muted
15:07:33 <Benjamin> zakim, mute me
15:07:33 <Zakim> Benjamin should now be muted
15:07:42 <Steven> Manu: Michael Hausenblas is reviewing the RDFa Core 1.1 LC doc
15:07:44 <Steven> Manu: Also note the change proposals that just went through, no one objected to the changes
15:07:51 <Nathan> 57,49,55,58 all past 7 days
15:08:01 <Steven> ... take a look at the upcoming two proposals to close issues, state potential objections if you have them
15:08:04 <manu> Topic: ISSUE-53: DataParser Upgrades
15:08:11 <Steven> ISSUE-53 - DataParser Upgrades - http://www.w3.org/2010/02/rdfa/track/issues/53
15:10:01 <Steven> Nathan: Main changes to this parser are 1) to support lightweight SAX-like parsers by adding a method
15:10:18 <Steven> ... to give a callback on each triple found
15:10:35 <ivan> q+
15:10:50 <Steven> ... 'parse' method may need discussion
15:11:30 <Steven> ... should we also support fragment parsing
15:11:37 <Steven> ... or just full document
15:11:39 <manu> ack ivan
15:11:50 <Steven> Ivan: Procedural point
15:12:13 <Steven> ... is there anyone who will implement the interface on mobile for feedback?
15:12:16 <manu> q+ on mobile implementation
15:12:34 <manu> ack manu
15:12:34 <Zakim> manu, you wanted to comment on mobile implementation
15:13:02 <Steven> Manu: LibRDFa is sax-based, keeping the footprint small, so I could give feedback
15:13:44 <Steven> Ivan: We need feedback
15:14:10 <Steven> Manu: Is a parser with low memory requirements enough?
15:14:26 <Steven> Ivan: We define our CR criteria, but they should be decent
15:14:36 <Steven> ... an implementation on a phone would be fine
15:15:00 <markbirbeck> We already support fragment parsing in a sense, since the input to the parse method is a DOMElement object, not a Document object.
15:15:01 <Steven> Shane: I have access to mobile environments
15:15:09 <Steven> ... we should definitely test it
15:15:20 <markbirbeck> MACRO11
15:15:25 <markbirbeck> brings back memories.
15:17:05 <Steven> Nathan: I see that Mark points out that we do DOMElement, which allows fragments, but a DOMElement is not the document node
15:17:35 <markbirbeck> @Steven: Right. However, we stipulate that the /entire/ document must be taken into account for context.
15:17:49 <markbirbeck> But we /could/ say that we start parsing at that node, and that's it.
15:18:01 <markbirbeck> (That's what my parser did.)
15:18:05 <Nathan> markbirbeck, yes but you can't throw in a Document because Document extends Node not Element
15:18:20 <markbirbeck> Oh yes, sorry.
15:18:52 <markbirbeck> @Nathan: Good point...but I think that is a mistake then. The intention was originally to be able to start parsing anywhere.
15:18:52 <Steven> [Scribe notes that web3r is Nathan]
15:19:44 <Steven> Nathan: there are two interfaces, one for each triple, one for the whole graph
15:20:18 <Steven> ... a third allows you to filter triples
15:20:27 <Steven> ... to keep memory requirements down
15:20:41 <Steven> Manu: I added some items at the bottom of the issue
15:20:53 <Steven> ... such as RDF Graph
15:21:17 <Steven> ... how does the parser callback have access to the filter method?
15:21:43 <Steven> Nathan: The filter is run by the parser itself, and the callback is only called if the filter allows it
15:22:13 <Steven> ... the callback is a graph
15:22:55 <Steven> ... the graph is first assembled, and filtered, then passed to the callback
15:23:09 <Steven> Manu: So 'run' is only called once at the end of parsing?
15:23:11 <Steven> Nathan: Yes
15:23:59 <Nathan> parse( document, function(graph) { //etc }, ?filter )
15:24:28 <Steven> Manu: If there is an error, how do they get hold of the processor graph?
15:24:35 <markbirbeck> @Nathan, Not quite following...how does it save memory to assemble the whole graph? Surely you want to reject triples during assembly? Or have I missed the point? :)
15:25:04 <Steven> Nathan: By accessing a member variable or method.
15:25:30 <Steven> Manu: Is the run method called with what could be parsed?
15:25:40 <Steven> Nathan: I think so
15:26:59 <Steven> Manu: LibRDFa ends parsing many times because of bad documents
15:27:09 <Nathan> @Mark, the whole graph isn't assembled, before the parser adds a triple to the graph it checks if it passes the filter or not before adding
15:27:18 <Steven> ... it is more useful to be able to use triples you have found than to give up completely
15:27:36 <markbirbeck> Like this?
15:27:39 <markbirbeck> parse( document, function( triple ) { if favoured( triple ) return true; return false; } )
15:27:47 <markbirbeck> Check each triple?
15:27:54 <markbirbeck> Only add if it matches?
15:29:36 <Nathan> @Mark, pretty much yes :) see: https://github.com/Nathan/rdfa-api/blob/master/source/parsers.js
15:29:47 <Steven> Ivan: The question is whether any of the triples found are in error because of the parsing error
15:30:35 <Steven> Manu: Triples can still be wrong without parsing errors
15:30:48 <Steven> Ivan: True
15:32:07 <Steven> Ivan: I would prefer not to get triples than to get wrong ones
15:32:32 <Steven> Manu: That should be up to the application
15:33:28 <markbirbeck> @Nathan, Thanks. Was confused by earlier discussion...it sounded like the filter was applied after the entire graph was assembled.
15:33:37 <Steven> Manu: Most pages are broken, but with librdfa, I can get lots of useful triples despite that
15:34:13 <Steven> q+
15:34:46 <Steven> ack s
15:35:14 <Steven> Steven: Isn't there a DOM, and we should define it in terms of the DOM you get, or would have got if you had built one
15:35:45 <Steven> Manu: Not possible with a SAX-based parser
15:37:59 <ivan> q+
15:38:08 <manu> ack ivan
15:38:19 <Steven> ... if you're not running in a browser environment, you don't have that option
15:38:50 <Steven> Ivan: I propose that we should keep the triples, but someone should analyse what sort of danger we are in
15:39:04 <Steven> ... I don't want incorrect triples.
15:39:27 <Steven> Manu: The parser returns false for incorrect input
15:40:07 <Steven> Nathan: I think that's fine
15:40:56 <Steven> ... how about if a profile can't be retrieved? Is that a parsing failure?
15:41:16 <Steven> Manu: I think so, a processing error should return false
15:41:58 <markbirbeck> Bearing in mind of course that a parser is not obliged to retrieve a profile. :)
15:42:32 <Steven> Manu: other issue is both graphs, default and processor. Option, should go in the callback?
15:42:48 <Steven> Nathan: Only pass in the default graph into the callback
15:43:08 <Steven> ... that would be wise
15:43:31 <Steven> Manu: Expose the processor graph via an attribute or a method?
15:43:38 <Steven> Nathan: A method
15:43:54 <Steven> ... would be friendlier
15:44:01 <Steven> Manu: Agree
15:44:22 <Steven> Manu: So that handles the parse method
15:44:44 <Steven> ... oh, one more thing
15:44:50 <markbirbeck> Doesn't that latter point depend on the graph v. store issue?
15:44:58 <Steven> ... do we support passing in IRI's?
15:44:59 <markbirbeck> If you pass in the store, you get both graphs anyway.
15:45:19 <Steven> Manu: Are there any MUSTs in what is supported?
15:45:29 <manu> Does parse() support: DOMElement, Document, text, IRI?
15:45:41 <Steven> Nathan: MUST be document, and I suggest text, just for existing RDF. Not sure about IRI
15:46:11 <Steven> ... you don't know what's at the other end
15:46:25 <manu> Document, text
15:46:51 <manu> <div>SOME RDFA IN HERE</div>
15:47:01 <Steven> Manu: Could I pass in a <div>?
15:47:27 <Steven> Ivan: You lose the context, prefixes, language, base, ...
15:47:33 <Steven> ... and get wrong triples
15:47:39 <markbirbeck> Obviously difficult to determine the subtleties of the discussion, but why not a node? I.e., element /or/ document.
15:48:05 <markbirbeck> You don't get 'wrong' triples if you know what you are parsing.
15:48:09 <Nathan> mark, agreed /if/ partial documents then has to be Node
15:48:26 <Steven> Manu: Snippet editing is a use-case
15:48:30 <markbirbeck> Lots of people are doing stuff where they embed RDFa in RDFa.
15:48:37 <markbirbeck> E.g., Drupal.
15:48:44 <Steven> Manu: Don't think we need to support DOM elements
15:48:59 <markbirbeck> So you might want to parse the /embedded/ RDFa using a different context to the one from the source document.
15:49:07 <Steven> Ivan: I don't even know what the host language is with a fragemtn
15:49:23 <Steven> Manu: OK to leave elements out?
15:49:29 <Steven> Nathan: I'd be happy with that
15:49:39 <markbirbeck> Seems unnecessary.
15:49:46 <markbirbeck> (To leave it out, I mean.)
15:50:45 <Nathan> drupal case, is that not 2 documents?
15:51:09 <Steven> Steven: Is Mark's example a suitable use-case?
15:51:25 <Steven> Manu: DOM element parsing is more like a convenience
15:51:49 <Steven> ... we can still support the Drupal case without DOM element
15:51:58 <ShaneM> I do not think that arbitrary element subtree parsing makes any sense on its own.  It has to be in the context of a document so there is a media type / base.
15:52:20 <manu> @markbirbeck: We don't need to process DOMElements if we support Document and text
15:52:50 <manu> @markbirbeck: DOMElement processing is more of a convenience method...
15:53:03 <markbirbeck> Do we not want to provide conenience? ;)
15:53:08 <Steven> rrsagent, make minutes
15:53:08 <RRSAgent> I have made the request to generate http://www.w3.org/2010/11/18-rdfa-minutes.html Steven
15:53:38 <manu> @markbirbeck, yes, but it's not too inconvenient to wrap the content in HTML/HEAD/BODY ?
15:53:54 <manu> @markbirbeck: Let's push off this decision until a bit later, until we can have a conversation w/ you about it.
15:53:55 <Nathan> @markbirbeck, libraries can easily without requiring this, especially if we just set the type to 'any' which we have to - the issue is half moot
15:54:01 <markbirbeck> The RDFa parsing model is recursive, so once you get past the root node, then you are always parsing elements anyway.
15:54:24 <markbirbeck> The context is passed down the calls, by accumulating from what's above.
15:54:35 <Steven> Nathan: If we're supporting more than Document, then we have to change the interface to ANY
15:54:41 <Steven> ... we can't prevent that\
15:55:02 <Steven> Manu: Right, but we'd use spec text to prevent it
15:55:05 <markbirbeck> So it's not really an argument to say that you need the context from the host document, because once you get past the root you're using a contrived context anyway.
15:55:40 <markbirbeck> @Manu: Sure. Sorry that I've missed yet another call. :(
15:55:41 <Steven> Manu: We have to make the minimum supported 'toparse' types clear - the minimum processing requirements in the spec must be clear
15:56:55 <Steven> Nathan: I agree
15:57:18 <Steven> Manu: We will have a future discussion with Mark about supporting fragment parsing/processing
15:57:29 <Steven> Topic: Any Other Business?
15:57:48 <Steven> Steven: Next Thursday is Thanksgiving, are we having a call?
15:58:04 <markbirbeck> I'll also ping Stephane because I think it's his use-case that has lodged in my mind.
15:58:26 <markbirbeck> (And if it's not, I'll see if I can work out where it came from.)
15:58:26 <Steven> Manu: I can't make the call. Please feel free to have a telcon without me
15:58:36 <Steven> Shane: I'm available
15:59:19 <Steven> Manu: I'll send an agenda for the rest of you
15:59:24 <Steven> [ADJOURN]
15:59:27 <Benjamin> zakim, unmute me
15:59:28 <Zakim> Benjamin should no longer be muted
15:59:29 <ivan> zakim, drop me
15:59:29 <Zakim> Ivan is being disconnected
15:59:30 <Zakim> -Ivan
15:59:32 <Zakim> -manu
15:59:37 <Zakim> -Nathan
15:59:39 <Zakim> -Shane
15:59:41 <Zakim> -Benjamin
15:59:43 <Zakim> -Steven
15:59:45 <Zakim> SW_RDFa()10:00AM has ended
15:59:46 <Zakim> Attendees were Ivan, manu, Nathan, +1.612.217.aaaa, Steven, +63.12.057.5aabb, Shane, Benjamin
15:59:53 <Steven> rrsagent, make minutes
15:59:53 <RRSAgent> I have made the request to generate http://www.w3.org/2010/11/18-rdfa-minutes.html Steven
# SPECIAL MARKER FOR CHATSYNC.  DO NOT EDIT THIS LINE OR BELOW.  SRCLINESUSED=00000226