14:28:29 RRSAgent has joined #rdfa 14:28:29 logging to http://www.w3.org/2011/11/17-rdfa-irc 14:28:31 RRSAgent, make logs world 14:28:31 Zakim has joined #rdfa 14:28:33 Zakim, this will be 7332 14:28:33 ok, trackbot; I see SW_RDFa()10:00AM scheduled to start in 32 minutes 14:28:34 Meeting: RDF Web Applications Working Group Teleconference 14:28:34 Date: 17 November 2011 14:28:41 Chair: Ivan 14:28:53 Regrets: Manu, Steven 14:29:13 sorry, i can only attend via IRC today 14:29:22 ivan has changed the topic to: Meeting Agenda, Nov 17, http://lists.w3.org/Archives/Public/public-rdfa-wg/2011Nov/0112.html 14:29:32 -> http://lists.w3.org/Archives/Public/public-rdfa-wg/2011Nov/0112.html agenda call 14:29:49 rrsagent, draft minutes 14:29:49 I have made the request to generate http://www.w3.org/2011/11/17-rdfa-minutes.html ivan 14:37:01 MacTed has joined #rdfa 14:39:42 ShaneM has joined #rdfa 14:56:47 zakim, dial ivan-voip 14:56:47 ok, ivan; the call is being made 14:56:48 SW_RDFa()10:00AM has now started 14:56:49 +Ivan 14:57:30 niklasl has joined #rdfa 14:58:20 +??P28 14:58:30 zakim, I am ??P28 14:58:30 +ShaneM; got it 14:59:54 +??P5 15:00:03 zakim, I am ??P5 15:00:12 +gkellogg; got it 15:00:27 scribe: Gregg 15:00:32 scribenick: gkellogg 15:01:15 +scor 15:01:22 scor has joined #rdfa 15:01:38 +[OpenLink] 15:01:55 zakim, who is on the phone? 15:01:55 On the phone I see Ivan, ShaneM, gkellogg, scor, [OpenLink] 15:01:59 Zakim, [OpenLink] is OpenLink_Software 15:01:59 zakim, OpenLink_Software is temporarily me 15:02:07 +OpenLink_Software; got it 15:02:09 +MacTed; got it 15:02:19 Topic: admin 15:02:32 -> http://www.w3.org/2010/02/rdfa/meetings/2011-11-03 last meeting's minutes 15:02:52 +??P3 15:02:58 zakim, I am ??P3 15:03:00 +niklasl; got it 15:03:16 Minutes accepted 15:03:45 Next Thursday's meeting would be on Thanksgiving in the U.S. 15:04:00 // Propose to cancel next meeting. 15:04:03 s/http:\/\/www.w3.org\/2010\/02\/rdfa\/meetings\/2011-11-03/http:\/\/www.w3.org\/2010\/02\/rdfa\/meetings\/2011-11-10/ 15:04:13 (that *might* be escaped properly) 15:04:45 On to "low-hanging" fruit 15:04:56 Topic: Low hanging fruits 15:05:03 ISSUE-97? 15:05:03 ISSUE-97 -- Determine if datetime should be supported in HTML5 -- open 15:05:03 http://www.w3.org/2010/02/rdfa/track/issues/97 15:05:42 ivan: had mailing list discussion and there seems general agreement that it should be accepted. 15:05:58 … some details to settle, being specific XSD datatypes to use. 15:06:13 … dateTime, time, date, gYear, …, duration 15:06:30 q+ 15:06:33 … My proposal to keep to HTML5 micro syntax doc: dateTime, date, time. 15:06:34 ack niklasl 15:06:38 q+ 15:06:51 niklasl: agree that HTML5 spec should dictate allowed values. 15:07:09 … not sure that the detail prevents using other XSD types 15:07:30 ack MacTed 15:07:32 … all types are possible to unambiguously match. We could do this if HTML5 allows for it. 15:07:59 MacTed: looking at the issue, it seems that TimeZones are catered for. If not, this must be addressed. 15:08:12 +1 to niklasl. let's have html5 dictate the allowed values. 15:08:13 ivan: timezones are supported. 15:08:21 … includes full microsyntax 15:08:25 q+ 15:08:27 q- 15:08:31 ack gkellogg 15:10:36 gkellogg: HTML5 iso a moving target, and we should indicate willingness to follow. 15:11:01 ivan: can make a proposal to add date, dateTime and date today, but intention is to follow the HTML5 spec. 15:11:16 s/date today/time today/ 15:11:35 PROPOSAL: HTML5+RDFa will add the time element with date, time, and dateTime, and will also express the intention to follow the time element discussion for subsequent datatypes 15:11:49 +1 15:11:49 +1 15:11:50 +1 15:11:50 +1 15:11:53 +1 15:11:54 +1 15:11:56 +1 15:12:02 RESOLVED: HTML5+RDFa will add the time element with date, time, and dateTime, and will also express the intention to follow the time element discussion for subsequent datatypes 15:12:39 ivan: side remark from jeni: we did say that if the lexical content does not match any datatype, then generate a plain literal. 15:12:53 … however, it should ignore language setting. 15:12:54 q+ 15:13:01 ack gkellogg 15:13:09 q+ to discuss language 15:13:20 q+ 15:13:56 ack ShaneM 15:13:56 ShaneM, you wanted to discuss language 15:14:00 gkellogg: also includes text content if there is no @datetime attribute. 15:14:12 shanem: concerned about "plethora" of special cases. 15:14:31 … @about on root element is another example, and issues with and 15:15:11 … including text content, otherwise it doesn't match gYear, ... 15:15:35 … another example of something to keep track of, also the fact that there's no language. 15:15:51 ivan: understand concern, but it generates better triples. 15:16:19 … for element content, we always say that literals that we generate keep whitespace. We should maintain the general rule. 15:16:53 … It may mean that some patterns aren't matched, but they can be constructed to match. 15:17:07 niklasl: we don't normalize? (no we don't) 15:17:15 q? 15:17:17 ack niklasl 15:17:24 "Thu, 17 Nov 2011 15:13:39 GMT" 15:17:27 … agree with language. 15:17:44 ivan: this does not follow micro syntax. 15:18:02 … would be a string (plain literal) with no language tag 15:18:23 q+ to get a clarification on element content 15:18:41 niklasl: don't think things are as bad as they seem, as we are making things helpful for authors. 15:18:43 ack ShaneM 15:18:44 ShaneM, you wanted to get a clarification on element content 15:18:58 shanem: might be confused about earlier +1 15:19:29 … thought we were agreeing on @datetime as dateTime, …. Otherwise no triple. 15:19:55 ivan: we said in case string does not match any datatypes we put out a plain literal with the content. 15:20:16 … it is the property plus the value as a plain literal without language. 15:20:26 … no XSD datatype 15:21:08 shanem: disagree with that, if it doesn't match the pattern, it should get language. 15:21:26 15:21:39 ivan: looking at nilasl's example, it is definitely in english. 15:22:17 PROPOSAL: if the datetime value does not match a datatype, it is put out as a plain literal, with possible language tag 15:22:23 +1 15:22:24 +1 15:22:24 +1 15:22:26 +1 15:22:26 +1 15:22:34 +1 15:22:36 RESOLVED: if the datetime value does not match a datatype, it is put out as a plain literal, with possible language tag 15:22:36 re: whitespace, this is what the spec says now: A conforming RDFa Processor must preserve white space in both plain literals and XML literals. However, it may be the case that the architecture in which a processor operates has made changes to the white space in a document before that document ever reaches the RDFa Processor (e.g., [XMLSCHEMA-1] processors are permitted to 'normalize' white space in attribute values - see section 3.1.4). To ensure maximum con 15:22:43 gkellogg: microdata-RDF should do the same. 15:22:57 ivan: manu must put this in the HTML5 document. 15:23:22 ACTION: fold into HTML5 document anything relevant from these minutes 15:23:22 Sorry, couldn't find user - fold 15:23:25 ISSUE-113? 15:23:25 ISSUE-113 -- Add the value attribute of the HTML data element as a possible literal target for property -- open 15:23:25 http://www.w3.org/2010/02/rdfa/track/issues/113 15:24:06 ivan: value of @value attribute would become a literal target. Similar to @datetime, it is a moving target. 15:24:08 can datatype effect the interpretation of @value on data ? 15:24:29 … don't think we should try to guess datatype, must be added specifically. 15:24:33 q+ 15:24:37 ack niklasl 15:25:09 niklasl: it might be that the value is intended to convey a "machine readable" value, so perhaps we should guess datatype. 15:25:32 ivan: we have to rely on what we know today. Based on HTML5 document, we should not go down the road to guessing datatype. 15:25:51 … language tags issue comes up again. 15:26:13 shanem: must be included, there's too much unknown. 15:26:14 q+ 15:26:19 ack gkellogg 15:26:37 I agree that the language should be preserved for @value on data 15:27:18 .. or a number 15:27:34 q+ 15:28:02 ack ivan 15:28:28 ivan: I don't think we should go down the route to try to guessing the intention of the author. 15:28:29 q+ to say that we can't know what @value means 15:28:55 q+ 15:29:00 … The @datetime is clearly there to describe time, for data we have no idea what it is for. It may create situations where the guess is wrong and do more harm than good. 15:29:10 ack ShaneM 15:29:10 ShaneM, you wanted to say that we can't know what @value means 15:29:14 … if author really wants datatypes, author should put it there. 15:29:22 15:29:53 ack niklasl 15:29:53 shanem: data has no semantics, its "data". Even if I could pattern match it, it could be wrong. 15:30:17 nilasl: it's too early for us to do anything based on maturity of HTML5 spec. 15:30:26 q+ 15:30:33 … it's called "data" as it's clearly intended for machine readable datatypes. 15:30:44 ack MacTed 15:30:45 … otherwise, it's just an alias for . 15:31:05 shanem: how can you be sure of intended datatype? 15:31:28 q+ 15:32:24 shanem: