RDFa Working Group Teleconference

Minutes of 17 June 2010

Agenda
http://lists.w3.org/Archives/Public/public-rdfa-wg/2010Jun/0056.html
Present
Manu Sporny, Steven Pemberton, Benjamin Adrian, Toby Inkster, Mark Birbeck, Shane McCarron
Regrets
Ivan Herman, Knud Möller
Chair
Manu Sporny
Scribe
Manu Sporny
IRC Log
Original and Editable Wiki Version
Resolutions
  1. RDFa should have an warning and error reporting mechanism. link
  2. 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. link
Topics
13:45:26 <RRSAgent> logging to http://www.w3.org/2010/06/17-rdfa-irc

RRSAgent IRC Bot: logging to http://www.w3.org/2010/06/17-rdfa-irc

13:45:56 <manu> trackbot, prepare telecon

Manu Sporny: trackbot, prepare telecon

13:45:58 <trackbot> RRSAgent, make logs world

Trackbot IRC Bot: RRSAgent, make logs world

13:46:00 <trackbot> Zakim, this will be 7332

Trackbot IRC Bot: Zakim, this will be 7332

13:46:00 <Zakim> ok, trackbot; I see SW_RDFa()10:00AM scheduled to start in 14 minutes

Zakim IRC Bot: 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: http://lists.w3.org/Archives/Public/public-rdfa-wg/2010Jun/0056.html
13:46:07 <manu> Chair: Manu
13:46:11 <manu> Scribe: Manu

(Scribe set to Manu Sporny)

13:46:19 <manu> scribenick: manu
13:47:51 <manu> Regrets: Ivan, Knud
13:57:48 <manu> Present: Manu, Steven, Benjamin, Toby, MarkB, Shane
14:00:15 <Zakim> SW_RDFa()10:00AM has now started

(No events recorded for 14 minutes)

Zakim IRC Bot: SW_RDFa()10:00AM has now started

14:00:19 <Zakim> +[IPcaller]

Zakim IRC Bot: +[IPcaller]

14:00:20 <manu> zakim, I am IPCaller

zakim, I am IPCaller

14:00:21 <Zakim> ok, manu, I now associate you with [IPcaller]

Zakim IRC Bot: ok, manu, I now associate you with [IPcaller]

14:00:27 <manu> zakim, who is on the call?

zakim, who is on the call?

14:00:33 <markbirbeck> zakim, code?

Mark Birbeck: zakim, code?

14:00:38 <Zakim> On the phone I see [IPcaller]

Zakim IRC Bot: On the phone I see [IPcaller]

14:00:42 <Zakim> the conference code is 7332 (tel:+1.617.761.6200 tel:+33.4.89.06.34.99 tel:+44.117.370.6152), markbirbeck

Zakim IRC Bot: the conference code is 7332 (tel:+1.617.761.6200 tel:+33.4.89.06.34.99 tel:+44.117.370.6152), markbirbeck

14:01:54 <Zakim> +ShaneM

Zakim IRC Bot: +ShaneM

14:03:57 <Steven> zakim, dial steven-617

Steven Pemberton: zakim, dial steven-617

14:03:57 <Zakim> ok, Steven; the call is being made

Zakim IRC Bot: ok, Steven; the call is being made

14:04:01 <Zakim> +Steven

Zakim IRC Bot: +Steven

14:23:18 <manu> Topic: ISSUE-26: Error Reporting Mechanism (on Ivan)

(No events recorded for 19 minutes)

1. ISSUE-26: Error Reporting Mechanism (on Ivan)

14:23:29 <Steven> issue-26?

Steven Pemberton: ISSUE-26?

14:23:29 <trackbot> ISSUE-26 -- Do we need an error reporting mechanism for RDFa? -- open

Trackbot IRC Bot: ISSUE-26 -- Do we need an error reporting mechanism for RDFa? -- open

14:23:29 <trackbot> http://www.w3.org/2010/02/rdfa/track/issues/26

Trackbot IRC Bot: http://www.w3.org/2010/02/rdfa/track/issues/26

14:24:24 <Zakim> -[IPcaller]

Zakim IRC Bot: -[IPcaller]

14:24:59 <Zakim> +[IPcaller]

Zakim IRC Bot: +[IPcaller]

14:26:27 <markbirbeck> q+

Mark Birbeck: q+

14:26:38 <Steven> ack mark

Steven Pemberton: 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?

Manu Sporny: 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.

Mark Birbeck: 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.

Mark Birbeck: 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.

Mark Birbeck: 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

Benjamin Adrian: +1 to add events about errors or warnings in the RDFa API

14:29:10 <manu> Manu: Anyone opposed to having an error mechanism?

Manu Sporny: Anyone opposed to having an error mechanism?

14:29:16 <manu> Steven: I think it would be useful to have.

Steven Pemberton: I think it would be useful to have.

14:29:40 <manu> PROPOSAL: RDFa should have a warning and error reporting mechanism.

PROPOSED: RDFa should have a warning and error reporting mechanism.

14:29:49 <manu> Manu: +1

Manu Sporny: +1

14:29:50 <markbirbeck> +1

Mark Birbeck: +1

14:29:53 <Benjamin> +1

Benjamin Adrian: +1

14:30:07 <Steven> +1 depending on form

Steven Pemberton: +1 depending on form

14:30:19 <tinkster> DataParser.parse(store, callback); /* callback is a function called back for each error. */

Toby Inkster: DataParser.parse(store, callback); /* callback is a function called back for each error. */

14:30:20 <ShaneM> +1

Shane McCarron: +1

14:31:02 <tinkster> +1 API should; -1 for Core having one.

Toby Inkster: +1 API should; -1 for Core having one.

14:31:08 <manu> RESOLVED: RDFa should have an warning and error reporting mechanism.

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.

Mark Birbeck: @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)

Manu Sporny: (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.

Toby Inkster: 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

Steven Pemberton: Not sure if I agree

14:33:54 <Steven> having an error graph could work

Steven Pemberton: having an error graph could work

14:34:16 <ShaneM> but RDF doesn';t really define how to access alternate graphs?

Shane McCarron: 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.

Mark Birbeck: @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

Steven Pemberton: 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.

Mark Birbeck: 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?

Benjamin Adrian: 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.

Shane McCarron: 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+

Mark Birbeck: q+

14:35:58 <manu> ack benjamin

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?

Zakim IRC Bot: 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.

Benjamin Adrian: I don't see the advantages of warnings and errors in the default graph.

14:36:30 <manu> ack mark

ack mark

14:36:40 <ShaneM> remember that there are many processors that are not embedded in a web page - no event mechanism

Shane McCarron: 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.

Mark Birbeck: 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?

Benjamin Adrian: @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.

Mark Birbeck: 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

Shane McCarron: okay - never mind

14:37:54 <Steven> Agree, bad idea to put them in the default graph

Steven Pemberton: Agree, bad idea to put them in the default graph

14:38:51 <manu> Manu: Let's move this discussion to the mailing list.

Manu Sporny: Let's move this discussion to the mailing list.

14:38:58 <manu> Topic: ISSUE-5: @datatype and rdf:XMLLiteral (on Toby)

2. ISSUE-5: @datatype and rdf:XMLLiteral (on Toby)

14:39:05 <manu> http://www.w3.org/2010/02/rdfa/track/issues/5

http://www.w3.org/2010/02/rdfa/track/issues/5

14:39:18 <tinkster> I don't think this is a contraversial issue at all. Move to resolve immediately?

Toby Inkster: I don't think this is a contraversial issue at all. Move to resolve immediately?

14:39:49 <tinkster> http://lists.w3.org/Archives/Public/public-rdfa-wg/2010Jun/0039.html!

Toby Inkster: http://lists.w3.org/Archives/Public/public-rdfa-wg/2010Jun/0039.html!

14:39:55 <markbirbeck> q+

Mark Birbeck: q+

14:40:07 <manu> Manu: (explains issue)

Manu Sporny: (explains issue)

14:40:11 <tinkster> that exclamation mark shouldn't be there.

Toby Inkster: that exclamation mark shouldn't be there.

14:40:23 <manu> Mark: We may want to have a token for XMLLiteral.

Mark Birbeck: We may want to have a token for XMLLiteral.

14:41:21 <tinkster> Mark++ e.g. datatype="xml"

Toby Inkster: Mark++ e.g. datatype="xml"

14:42:08 <markbirbeck> @tinkster: Actually, you're right...that's much better.:)

Mark Birbeck: @tinkster: Actually, you're right...that's much better.:)

14:42:14 <ShaneM> ++ tinkster

Shane McCarron: ++ tinkster

14:42:24 <Steven> +1

Steven Pemberton: +1

14:42:26 <ShaneM> +1

Shane McCarron: +1

14:42:36 <markbirbeck> +1

Mark Birbeck: +1

14:42:38 <Benjamin> +1

Benjamin Adrian: +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.

PROPOSED: 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.

PROPOSED: 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

Manu Sporny: +1

14:44:20 <Steven> +1

Steven Pemberton: +1

14:44:21 <Benjamin> +1

Benjamin Adrian: +1

14:44:23 <tinkster> +1

Toby Inkster: +1

14:44:25 <markbirbeck> +1

Mark Birbeck: +1

14:44:32 <Steven> ZAKIM, WHO IS NOISY?

Steven Pemberton: ZAKIM, WHO IS NOISY?

14:44:32 <ShaneM> +1

Shane McCarron: +1

14:44:42 <Zakim> Steven, listening for 10 seconds I heard sound from the following: Benjamin (4%), Steven (8%), ShaneM.a (44%)

Zakim IRC Bot: 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.

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?

Steven Pemberton: zakim, who is noisy?

14:45:17 <Zakim> Steven, listening for 10 seconds I heard sound from the following: ShaneM.a (10%)

Zakim IRC Bot: Steven, listening for 10 seconds I heard sound from the following: ShaneM.a (10%)

14:45:28 <ShaneM> zakim, mute me

Shane McCarron: zakim, mute me

14:45:28 <Zakim> ShaneM.a should now be muted

Zakim IRC Bot: ShaneM.a should now be muted

14:45:31 <Steven> zakim, mute shane temporarily

Steven Pemberton: zakim, mute shane temporarily

14:45:31 <Zakim> ShaneM.a was already muted, Steven

Zakim IRC Bot: ShaneM.a was already muted, Steven

14:45:53 <ShaneM> zakim, unmute me

Shane McCarron: zakim, unmute me

14:45:53 <Zakim> ShaneM.a should no longer be muted

Zakim IRC Bot: ShaneM.a should no longer be muted

14:45:55 <manu> Topic: ISSUE-20: Deep Processing of XMLLiterals (on Mark)

3. ISSUE-20: Deep Processing of XMLLiterals (on Mark)

14:46:05 <Steven> issue-20?

Steven Pemberton: 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

Trackbot IRC Bot: 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> http://www.w3.org/2010/02/rdfa/track/issues/20

Trackbot IRC Bot: http://www.w3.org/2010/02/rdfa/track/issues/20

14:46:39 <ShaneM> definitely not

Shane McCarron: definitely not

14:46:40 <manu> Manu: (explains issue)

Manu Sporny: (explains issue)

14:46:56 <Steven> I need a use case

Steven Pemberton: 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

Manu Sporny: 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.

Toby Inkster: there are certainly good use cases.

14:47:07 <ShaneM> it would break compatibility in a dramatic manner.,

Shane McCarron: 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.

Toby Inkster: 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.

Toby Inkster: e.g. use case a blog. blog entry titles, authors, etc are marked up in RDFa.

14:49:06 <manu> http://lists.w3.org/Archives/Public/public-rdfa-wg/2010Mar/0092.html

http://lists.w3.org/Archives/Public/public-rdfa-wg/2010Mar/0092.html

14:49:21 <tinkster> each entry has the content as an XMLLiteral.

Toby Inkster: 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...

Toby Inkster: 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...

Mark Birbeck: 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.

Mark Birbeck: 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.

Mark Birbeck: 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.

Manu Sporny: Move discussion of this to the mailing list.

14:52:06 <manu> Topic: ISSUE-27: Relative URIs (on Shane)

4. ISSUE-27: Relative URIs (on Shane)

14:52:47 <Steven> issue-27?

Steven Pemberton: ISSUE-27?

14:52:47 <trackbot> ISSUE-27 -- Does TermorCURIEorURI allow relative URIs? -- open

Trackbot IRC Bot: ISSUE-27 -- Does TermorCURIEorURI allow relative URIs? -- open

14:52:47 <trackbot> http://www.w3.org/2010/02/rdfa/track/issues/27

Trackbot IRC Bot: http://www.w3.org/2010/02/rdfa/track/issues/27

14:52:58 <manu> Manu: Any arguments for/against?

Manu Sporny: 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.

Shane McCarron: 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+

Mark Birbeck: 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.

Toby Inkster: 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?

Steven Pemberton: 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.

Mark Birbeck: I agree with Steven, how do we ban this? I think this was originally intended.

14:55:43 <ShaneM> q+ to argue with mark ;-)

Shane McCarron: q+ to argue with mark ;-)

14:55:52 <Steven> ack mark

Steven Pemberton: 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.

Mark Birbeck: 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

ack mark

14:55:56 <Steven> ack shane

Steven Pemberton: ack shane

14:55:56 <Zakim> ShaneM.a, you wanted to argue with mark ;-)

Zakim IRC Bot: ShaneM.a, you wanted to argue with mark ;-)

14:55:56 <manu> ack shane

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.

Shane McCarron: 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?

Shane McCarron: 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. ←

Shane McCarron: 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.

Manu Sporny: 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.

Mark Birbeck: 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?

Manu Sporny: 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.

Mark Birbeck: 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?

Mark Birbeck: 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.

Toby Inkster: 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.

Toby Inkster: 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.

Manu Sporny: 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+

Mark Birbeck: q+

15:03:23 <ShaneM> http://www.w3.org/2010/02/rdfa/sources/rdfa-core/#s_curieprocessing

Shane McCarron: http://www.w3.org/2010/02/rdfa/sources/rdfa-core/#s_curieprocessing

15:03:43 <manu> q+ to end telecon

q+ to end telecon

15:04:24 <manu> Mark: So, basically if we "prevent" relative URIs... we have to detect them.

Mark Birbeck: So, basically if we "prevent" relative URIs... we have to detect them.



Formatted by CommonScribe


This revision (#2) generated 2010-06-17 15:42:41 UTC by 'msporny', comments: 'Added agenda.'