Chatlog 2010-06-17

From RDFa Working Group Wiki
Jump to: navigation, search

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

13:45:26 <RRSAgent> RRSAgent has joined #rdfa
13:45:26 <RRSAgent> logging to
13:45:56 <manu> trackbot, prepare telecon
13:45:58 <trackbot> RRSAgent, make logs world
13:46:00 <trackbot> Zakim, this will be 7332
13:46:00 <Zakim> ok, trackbot; I see SW_RDFa()10:00AM scheduled to start in 14 minutes
13:46:01 <trackbot> Meeting: RDFa Working Group Teleconference
13:46:01 <trackbot> Date: 17 June 2010
13:46:05 <manu> Agenda:
13:46:07 <manu> Chair: Manu
13:46:11 <manu> Scribe: Manu
13:46:19 <manu> scribenick: manu
13:47:51 <manu> Regrets: Ivan, Knud
13:48:50 <Steven> Steven has joined #rdfa
13:52:02 <Benjamin> Benjamin has joined #rdfa
13:57:48 <manu> Present: Manu, Steven, Benjamin, Toby, MarkB, Shane
14:00:15 <Zakim> SW_RDFa()10:00AM has now started
14:00:19 <Zakim> +[IPcaller]
14:00:20 <manu> zakim, I am IPCaller
14:00:21 <Zakim> ok, manu, I now associate you with [IPcaller]
14:00:27 <manu> zakim, who is on the call?
14:00:33 <markbirbeck> zakim, code?
14:00:38 <Zakim> On the phone I see [IPcaller]
14:00:38 <tinkster> tinkster has joined #rdfa
14:00:42 <Zakim> the conference code is 7332 (tel:+1.617.761.6200 tel:+ tel:+44.117.370.6152), markbirbeck
14:01:54 <Zakim> +ShaneM
14:03:57 <Steven> zakim, dial steven-617
14:03:57 <Zakim> ok, Steven; the call is being made
14:04:01 <Zakim> +Steven
14:23:18 <manu> Topic: ISSUE-26: Error Reporting Mechanism (on Ivan)
14:23:29 <Steven> issue-26?
14:23:29 <trackbot> ISSUE-26 -- Do we need an error reporting mechanism for RDFa? -- open
14:23:29 <trackbot>
14:24:24 <Zakim> -[IPcaller]
14:24:59 <Zakim> +[IPcaller]
14:26:27 <markbirbeck> q+
14:26:38 <Steven> ack mark
14:27:05 <manu> Manu: This concerns two things... do we want an error reporting mechanism? if so, what does it look like?
14:27:27 <manu> Mark: Well, you say RDFa Processor, but we also have an RDFa API now. We may have to come at it from two directions.
14:27:46 <manu> Mark: We may want to have something about this on RDFa Core, but we may want to also have something in the RDFa API spec.
14:28:11 <manu> Mark: Perhaps we shouldn't put Events in RDFa Core... but maybe we want to spec Events in RDFa API.
14:28:29 <Benjamin> +1 to add events  about errors or warnings in the RDFa API
14:29:10 <manu> Manu: Anyone opposed to having an error mechanism?
14:29:16 <manu> Steven: I think it would be useful to have.
14:29:40 <manu> PROPOSAL: RDFa should have a warning and error reporting mechanism.
14:29:49 <manu> Manu: +1
14:29:50 <markbirbeck> +1
14:29:53 <Benjamin> +1
14:30:07 <Steven> +1 depending on form
14:30:19 <tinkster> DataParser.parse(store, callback); /* callback is a function called back for each error. */
14:30:20 <ShaneM> +1
14:31:02 <tinkster> +1 API should; -1 for Core having one.
14:31:08 <manu> RESOLVED: RDFa should have an warning and error reporting mechanism.
14:32:02 <markbirbeck> @tinkster Yes, that's one option. I favour using DOM 2 Events myself, but maybe that just means that your 'callback' is an EventHandler object.
14:33:08 <manu> Manu: (explains current proposal)
14:33:20 <tinkster> A processor implementing RDFa but not the RDFa API might want to have a method of passing back errors to whatever invoked it, but what that method is seems beyond the scope of RDFa to me. The RDFa API seems the only place where we should get involved in how errors are reported back.
14:33:48 <Steven> Not sure if I agree
14:33:54 <Steven> having an error graph could work
14:34:16 <ShaneM> but RDF doesn';t really define how to access alternate graphs?
14:34:28 <markbirbeck> @tinkster: I don't think there's anything wrong with defining an error graph in core. But definitely it shouldn't define behaviour like events. That's for the API.
14:34:47 <Steven> agree on that
14:35:20 <manu> Mark: Shane, I think that's true, but this can be processor-specific. All we're really saying is that we should define some RDF terminology to define what errors are... and that these are available to the processor in a certain way.
14:35:50 <Benjamin> q+ on asking What is the advantage of storing warning and errors instead of just raising them as events?
14:35:54 <manu> Shane: What if we define /something/ in the RDFa namespace that mean error or warning, but they can be returned in the regular graph.
14:35:55 <markbirbeck> q+
14:35:58 <manu> ack benjamin
14:35:58 <Zakim> Benjamin, you wanted to comment on asking What is the advantage of storing warning and errors instead of just raising them as events?
14:36:09 <manu> Benjamin: I don't see the advantages of warnings and errors in the default graph.
14:36:30 <manu> ack mark
14:36:40 <ShaneM> remember that there are many processors that are not embedded in a web page - no event mechanism
14:36:56 <manu> Mark: There are two things going on here - whether we have triples that indicate warnings, that's one question, whether or not they're in the default graph is another question.
14:37:15 <Benjamin> @Shane, ok I see the point, but how do XML parsers solve this issue?
14:37:17 <manu> Mark: People are doing this in different ways at the moment... I don't think it should be in the default graph.
14:37:49 <ShaneM> okay - never mind
14:37:54 <Steven> Agree, bad idea to put them in the default graph
14:38:51 <manu> Manu: Let's move this discussion to the mailing list.
14:38:58 <manu> Topic: ISSUE-5: @datatype and rdf:XMLLiteral (on Toby)
14:39:05 <manu>
14:39:18 <tinkster> I don't think this is a contraversial issue at all. Move to resolve immediately?
14:39:49 <tinkster>!
14:39:55 <markbirbeck> q+
14:40:07 <manu> Manu: (explains issue)
14:40:11 <tinkster> that exclamation mark shouldn't be there.
14:40:23 <manu> Mark: We may want to have a token for XMLLiteral.
14:41:21 <tinkster> Mark++ e.g. datatype="xml"
14:42:08 <markbirbeck> @tinkster: Actually, you're right...that's much better.:)
14:42:14 <ShaneM> ++ tinkster
14:42:24 <Steven> +1
14:42:26 <ShaneM> +1
14:42:36 <markbirbeck> +1
14:42:38 <Benjamin> +1
14:43:20 <manu> PROPOSAL: Add language to the RDFa Core specification that states that when a CURIE in a datatype is expanded, if it is the rdf:XMLLiteral datatype, generate an XMLLiteral.
14:43:57 <manu> PROPOSAL: Add language to the RDFa Core specification that states that when a CURIE in a datatype is expanded, if it is the RDF XMLLiteral URL, generate an XMLLiteral.
14:44:16 <manu> Manu: +1
14:44:20 <Steven> +1
14:44:21 <Benjamin> +1
14:44:23 <tinkster> +1
14:44:25 <markbirbeck> +1
14:44:32 <Steven> ZAKIM, WHO IS NOISY?
14:44:32 <ShaneM> +1
14:44:42 <Zakim> Steven, listening for 10 seconds I heard sound from the following: Benjamin (4%), Steven (8%), ShaneM.a (44%)
14:44:44 <manu> RESOLVED: Add language to the RDFa Core specification that states that when a CURIE in a datatype is expanded, if it is the RDF XMLLiteral URL, generate an XMLLiteral.
14:45:07 <Steven> zakim, who is noisy?
14:45:17 <Zakim> Steven, listening for 10 seconds I heard sound from the following: ShaneM.a (10%)
14:45:28 <ShaneM> zakim, mute me
14:45:28 <Zakim> ShaneM.a should now be muted
14:45:31 <Steven> zakim, mute shane temporarily
14:45:31 <Zakim> ShaneM.a was already muted, Steven
14:45:53 <ShaneM> zakim, unmute me
14:45:53 <Zakim> ShaneM.a should no longer be muted
14:45:55 <manu> Topic: ISSUE-20: Deep Processing of XMLLiterals (on Mark)
14:46:05 <Steven> issue-20?
14:46:05 <trackbot> ISSUE-20 -- XMLLiteral content isn't processed for RDFa attributes in RDFa 1.0 - should this change in RDFa 1.1? -- open
14:46:05 <trackbot>
14:46:39 <ShaneM> definitely not
14:46:40 <manu> Manu: (explains issue)
14:46:56 <Steven> I need a use case
14:46:59 <manu> Manu: Anybody want to change default behavior from RDFa 1.0 - extract triples from XML Literal
14:47:07 <tinkster> there are certainly good use cases.
14:47:07 <ShaneM> it would break compatibility in a dramatic manner.,
14:47:39 <tinkster> it would break backcompat, so would need to be done with an explicit opt-in.
14:49:00 <tinkster> e.g. use case a blog. blog entry titles, authors, etc are marked up in RDFa.
14:49:06 <manu>
14:49:21 <tinkster> each entry has the content as an XMLLiteral.
14:49:48 <tinkster> but perhaps the content contains data that could also be usefully exposed as RDFa...
14:50:13 <manu> Mark: I wonder whether or not we could hold off on this...
14:50:47 <manu> Mark: I thought that most of the scenarios where you'd want XMLLiterals to "store" data - most of those scenarios could be solved using CDATA or COMMENTs.
14:51:17 <manu> Mark: Perhaps we can escape the data in-line, so the RDFa parser stores it literally... if it is in "the structure" parse it as is.
14:51:51 <manu> Manu: Move discussion of this to the mailing list.
14:52:06 <manu> Topic: ISSUE-27: Relative URIs (on Shane)
14:52:47 <Steven> issue-27?
14:52:47 <trackbot> ISSUE-27 -- Does TermorCURIEorURI allow relative URIs? -- open
14:52:47 <trackbot>
14:52:58 <manu> Manu: Any arguments for/against?
14:54:13 <manu> Shane: I don't think allowing relative URIs in a datatype make sense - it was not what we envisioned when we created datatype.
14:54:18 <markbirbeck> q+
14:54:38 <tinkster> An argument against might be future extensibility. By disallowing these now, RDFa 1.2/2.0 might like to define some kind of token which looks a bit like a relative URI.
14:54:44 <manu> Steven: I'm uncomfortable with not allowing things... what do we lose by allowing relative URIs?
14:55:00 <manu> Mark: I agree with Steven, how do we ban this? I think this was originally intended.
14:55:43 <ShaneM> q+ to argue with mark ;-)
14:55:52 <Steven> ack mark
14:55:52 <manu> Mark: It's a bit like the discussion on absolute URIs - we had issues with distinguishing with QNames - if the prefix is undefined, it's a URI.
14:55:54 <manu> ack mark
14:55:56 <Steven> ack shane
14:55:56 <Zakim> ShaneM.a, you wanted to argue with mark ;-)
14:55:56 <manu> ack shane
14:56:38 <manu> Shane: You're right, except that this means that if I use a token and it's not defined, it's a relative URI.
14:57:02 <manu> Shane: Is it relative to the current vocab URI? Or the current base?
14:58:02 <ShaneM> how does this concept work in conjunction with this resolution:  RESOLVED: RDFa attributes containing all invalid values should be interpreted as those attributes with an empty attribute value. ←
14:58:09 <manu> Manu: This is like our junk triples discussion.
14:58:29 <manu> Mark: Well, they're not junk triples... they meant to create a triple, it's just the wrong one.
14:58:57 <manu> Manu: What's the use case for this?
14:59:10 <manu> Mark: If you're doing something like an OWL ontology, the predicates are the values in the ontology.
14:59:53 <manu> Mark: It's not a strong argument for it... but Stevens opening remark is fair... what do we gain by removing it?
15:00:01 <tinkster> If you're doing something like an OWL ontology, you can just set vocab="..." on your entire document anyway.
15:00:23 <tinkster> We're not "removing it" per se - they're not allowed in RDFa 1.0 anyway.
15:02:27 <manu> Manu: Sounds like we don't have a s trong use case... we're not removing it, just saying it's undefined and it doesn't generate a triple.
15:03:16 <markbirbeck> q+
15:03:23 <ShaneM>
15:03:43 <manu> q+ to end telecon
15:04:24 <manu> Mark: So, basically if we "prevent" relative URIs... we have to detect them.