IRC log of rdfa on 2011-11-17

Timestamps are in UTC.

14:28:29 [RRSAgent]: RRSAgent has joined #rdfa
14:28:29 [RRSAgent]: logging to http://www.w3.org/2011/11/17-rdfa-irc
14:28:31 [trackbot]: RRSAgent, make logs world
14:28:31 [Zakim]: Zakim has joined #rdfa
14:28:33 [trackbot]: Zakim, this will be 7332
14:28:33 [Zakim]: ok, trackbot; I see SW_RDFa()10:00AM scheduled to start in 32 minutes
14:28:34 [trackbot]: Meeting: RDF Web Applications Working Group Teleconference
14:28:34 [trackbot]: Date: 17 November 2011
14:28:41 [ivan]: Chair: Ivan
14:28:53 [ivan]: Regrets: Manu, Steven
14:29:13 [tomayac]: sorry, i can only attend via IRC today
14:29:22 [ivan]: 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 [ivan]: -> http://lists.w3.org/Archives/Public/public-rdfa-wg/2011Nov/0112.html agenda call
14:29:49 [ivan]: rrsagent, draft minutes
14:29:49 [RRSAgent]: I have made the request to generate http://www.w3.org/2011/11/17-rdfa-minutes.html ivan
14:37:01 [MacTed]: MacTed has joined #rdfa
14:39:42 [ShaneM]: ShaneM has joined #rdfa
14:56:47 [ivan]: zakim, dial ivan-voip
14:56:47 [Zakim]: ok, ivan; the call is being made
14:56:48 [Zakim]: SW_RDFa()10:00AM has now started
14:56:49 [Zakim]: +Ivan
14:57:30 [niklasl]: niklasl has joined #rdfa
14:58:20 [Zakim]: +??P28
14:58:30 [ShaneM]: zakim, I am ??P28
14:58:30 [Zakim]: +ShaneM; got it
14:59:54 [Zakim]: +??P5
15:00:03 [gkellogg]: zakim, I am ??P5
15:00:12 [Zakim]: +gkellogg; got it
15:00:27 [ivan]: scribe: Gregg
15:00:32 [ivan]: scribenick: gkellogg
15:01:15 [Zakim]: +scor
15:01:22 [scor]: scor has joined #rdfa
15:01:38 [Zakim]: +[OpenLink]
15:01:55 [scor]: zakim, who is on the phone?
15:01:55 [Zakim]: On the phone I see Ivan, ShaneM, gkellogg, scor, [OpenLink]
15:01:59 [MacTed]: Zakim, [OpenLink] is OpenLink_Software
15:01:59 [MacTed]: zakim, OpenLink_Software is temporarily me
15:02:07 [Zakim]: +OpenLink_Software; got it
15:02:09 [Zakim]: +MacTed; got it
15:02:19 [ivan]: Topic: admin
15:02:32 [ivan]: -> http://www.w3.org/2010/02/rdfa/meetings/2011-11-03 last meeting's minutes
15:02:52 [Zakim]: +??P3
15:02:58 [niklasl]: zakim, I am ??P3
15:03:00 [Zakim]: +niklasl; got it
15:03:16 [gkellogg]: Minutes accepted
15:03:45 [gkellogg]: Next Thursday's meeting would be on Thanksgiving in the U.S.
15:04:00 [gkellogg]: // Propose to cancel next meeting.
15:04:03 [MacTed]: 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 [MacTed]: (that *might* be escaped properly)
15:04:45 [gkellogg]: On to "low-hanging" fruit
15:04:56 [ivan]: Topic: Low hanging fruits
15:05:03 [ivan]: ISSUE-97?
15:05:03 [trackbot]: ISSUE-97 -- Determine if datetime should be supported in HTML5 -- open
15:05:03 [trackbot]: http://www.w3.org/2010/02/rdfa/track/issues/97
15:05:42 [gkellogg]: ivan: had mailing list discussion and there seems general agreement that it should be accepted.
15:05:58 [gkellogg]: … some details to settle, being specific XSD datatypes to use.
15:06:13 [gkellogg]: … dateTime, time, date, gYear, …, duration
15:06:30 [niklasl]: q+
15:06:33 [gkellogg]: … My proposal to keep to HTML5 micro syntax doc: dateTime, date, time.
15:06:34 [ivan]: ack niklasl
15:06:38 [MacTed]: q+
15:06:51 [gkellogg]: niklasl: agree that HTML5 spec should dictate allowed values.
15:07:09 [gkellogg]: … not sure that the detail prevents using other XSD types
15:07:30 [ivan]: ack MacTed
15:07:32 [gkellogg]: … all types are possible to unambiguously match. We could do this if HTML5 allows for it.
15:07:59 [gkellogg]: MacTed: looking at the issue, it seems that TimeZones are catered for. If not, this must be addressed.
15:08:12 [tomayac]: +1 to niklasl. let's have html5 dictate the allowed values.
15:08:13 [gkellogg]: ivan: timezones are supported.
15:08:21 [gkellogg]: … includes full microsyntax
15:08:25 [gkellogg]: q+
15:08:27 [MacTed]: q-
15:08:31 [ivan]: ack gkellogg
15:10:36 [gkellogg]: gkellogg: HTML5 iso a moving target, and we should indicate willingness to follow.
15:11:01 [gkellogg]: ivan: can make a proposal to add date, dateTime and date today, but intention is to follow the HTML5 spec.
15:11:16 [MacTed]: s/date today/time today/
15:11:35 [ivan]: 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 [gkellogg]: +1
15:11:49 [niklasl]: +1
15:11:50 [ivan]: +1
15:11:50 [tomayac]: +1
15:11:53 [scor]: +1
15:11:54 [ShaneM]: +1
15:11:56 [MacTed]: +1
15:12:02 [ivan]: 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 [gkellogg]: 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 [gkellogg]: … however, it should ignore language setting.
15:12:54 [gkellogg]: q+
15:13:01 [ivan]: ack gkellogg
15:13:09 [ShaneM]: q+ to discuss language
15:13:20 [niklasl]: q+
15:13:56 [ivan]: ack ShaneM
15:13:56 [Zakim]: ShaneM, you wanted to discuss language
15:14:00 [gkellogg]: gkellogg: also includes text content if there is no @datetime attribute.
15:14:12 [gkellogg]: shanem: concerned about "plethora" of special cases.
15:14:31 [gkellogg]: … @about on root element is another example, and issues with <head> and <body>
15:15:11 [gkellogg]: … including text content, otherwise it doesn't match gYear, ...
15:15:35 [gkellogg]: … another example of something to keep track of, also the fact that there's no language.
15:15:51 [gkellogg]: ivan: understand concern, but it generates better triples.
15:16:19 [gkellogg]: … for element content, we always say that literals that we generate keep whitespace. We should maintain the general rule.
15:16:53 [gkellogg]: … It may mean that some patterns aren't matched, but they can be constructed to match.
15:17:07 [gkellogg]: niklasl: we don't normalize? (no we don't)
15:17:15 [ivan]: q?
15:17:17 [ivan]: ack niklasl
15:17:24 [niklasl]: "Thu, 17 Nov 2011 15:13:39 GMT"
15:17:27 [gkellogg]: … agree with language.
15:17:44 [gkellogg]: ivan: this does not follow micro syntax.
15:18:02 [gkellogg]: … would be a string (plain literal) with no language tag
15:18:23 [ShaneM]: q+ to get a clarification on element content
15:18:41 [gkellogg]: niklasl: don't think things are as bad as they seem, as we are making things helpful for authors.
15:18:43 [ivan]: ack ShaneM
15:18:44 [Zakim]: ShaneM, you wanted to get a clarification on element content
15:18:58 [gkellogg]: shanem: might be confused about earlier +1
15:19:29 [gkellogg]: … thought we were agreeing on @datetime as dateTime, …. Otherwise no triple.
15:19:55 [gkellogg]: ivan: we said in case string does not match any datatypes we put out a plain literal with the content.
15:20:16 [gkellogg]: … it is the property plus the value as a plain literal without language.
15:20:26 [gkellogg]: … no XSD datatype
15:21:08 [gkellogg]: shanem: disagree with that, if it doesn't match the pattern, it should get language.
15:21:26 [ShaneM]: <time property="my:time">its time to fly</time>
15:21:39 [gkellogg]: ivan: looking at nilasl's example, it is definitely in english.
15:22:17 [ivan]: 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 [gkellogg]: +1
15:22:24 [ShaneM]: +1
15:22:24 [scor]: +1
15:22:26 [ivan]: +1
15:22:26 [niklasl]: +1
15:22:34 [MacTed]: +1
15:22:36 [ivan]: 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 [ShaneM]: 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]: gkellogg: microdata-RDF should do the same.
15:22:57 [gkellogg]: ivan: manu must put this in the HTML5 document.
15:23:22 [gkellogg]: ACTION: fold into HTML5 document anything relevant from these minutes
15:23:22 [trackbot]: Sorry, couldn't find user - fold
15:23:25 [ivan]: ISSUE-113?
15:23:25 [trackbot]: ISSUE-113 -- Add the value attribute of the HTML data element as a possible literal target for property -- open
15:23:25 [trackbot]: http://www.w3.org/2010/02/rdfa/track/issues/113
15:24:06 [gkellogg]: ivan: value of @value attribute would become a literal target. Similar to @datetime, it is a moving target.
15:24:08 [ShaneM]: can datatype effect the interpretation of @value on data ?
15:24:29 [gkellogg]: … don't think we should try to guess datatype, must be added specifically.
15:24:33 [niklasl]: q+
15:24:37 [ivan]: ack niklasl
15:25:09 [gkellogg]: niklasl: it might be that the value is intended to convey a "machine readable" value, so perhaps we should guess datatype.
15:25:32 [gkellogg]: 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 [gkellogg]: … language tags issue comes up again.
15:26:13 [gkellogg]: shanem: must be included, there's too much unknown.
15:26:14 [gkellogg]: q+
15:26:19 [ivan]: ack gkellogg
15:26:37 [ShaneM]: I agree that the language should be preserved for @value on data
15:27:18 [niklasl]: .. or a number
15:27:34 [ivan]: q+
15:28:02 [ivan]: ack ivan
15:28:28 [gkellogg]: ivan: I don't think we should go down the route to try to guessing the intention of the author.
15:28:29 [ShaneM]: q+ to say that we can't know what @value means
15:28:55 [niklasl]: q+
15:29:00 [gkellogg]: … 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 [ivan]: ack ShaneM
15:29:10 [Zakim]: ShaneM, you wanted to say that we can't know what @value means
15:29:14 [gkellogg]: … if author really wants datatypes, author should put it there.
15:29:22 [ShaneM]: <data xml:lang='lt' value='veni, vidi, vici' />
15:29:53 [ivan]: ack niklasl
15:29:53 [gkellogg]: shanem: data has no semantics, its "data". Even if I could pattern match it, it could be wrong.
15:30:17 [gkellogg]: nilasl: it's too early for us to do anything based on maturity of HTML5 spec.
15:30:26 [MacTed]: q+
15:30:33 [gkellogg]: … it's called "data" as it's clearly intended for machine readable datatypes.
15:30:44 [ivan]: ack MacTed
15:30:45 [gkellogg]: … otherwise, it's just an alias for <span>.
15:31:05 [gkellogg]: shanem: how can you be sure of intended datatype?
15:31:28 [ivan]: q+
15:32:24 [gkellogg]: shanem: <time> is clear, but <data> is not.
15:32:34 [gkellogg]: … too many possibilities.
15:32:36 [ivan]: ack ivan
15:33:14 [gkellogg]: ivan: I could say that I might intuit the language of a string and add the language to the literal. That's not our job.
15:33:47 [gkellogg]: ivan: if HTML5 comes up with a micro syntax, we can look at again. Until then, we should not try to guess it.
15:35:22 [gkellogg]: niklasl: revisit if the HTML5 spec becomes more clear.
15:35:54 [ivan]: PROPOSAL: Accept a <data> element with the @value attribute generating a plain literal with language retained; the HTML5+RDFa document will follow possible evolution of that element defintion for datatypes
15:36:01 [niklasl]: +1
15:36:07 [scor]: +1
15:36:10 [gkellogg]: +1
15:36:10 [MacTed]: +1
15:36:10 [tomayac]: +1
15:36:13 [ivan]: +1
15:36:17 [ShaneM]: +1
15:36:23 [ivan]: RESOLVED: Accept a <data> element with the @value attribute generating a plain literal with language retained; the HTML5+RDFa document will follow possible evolution of that element defintion for datatypes
15:36:27 [scor]: s/defintion/definition
15:36:59 [gkellogg]: ACTION: manu1 to resolve to implement 97 and 113
15:36:59 [trackbot]: Created ACTION-104 - Resolve to implement 97 and 113 [on Manu Sporny - due 2011-11-24].
15:37:04 [ivan]: ISSUE-116?
15:37:04 [trackbot]: ISSUE-116 -- Consider owl terms for vocab expansion -- open
15:37:04 [trackbot]: http://www.w3.org/2010/02/rdfa/track/issues/116
15:37:45 [gkellogg]: issue: this would mean adding to the current set of terms owl:equivalentProperty and owl:equivalentClass.
15:37:45 [trackbot]: Created ISSUE-120 - This would mean adding to the current set of terms owl:equivalentProperty and owl:equivalentClass. ; please complete additional details at http://www.w3.org/2010/02/rdfa/track/issues/120/edit .
15:38:20 [gkellogg]: gkellogg: didn't mean to create an issue, will remove it :(
15:38:57 [gkellogg]: q+
15:38:57 [ivan]: PROPOSED: add owl:equivalentProperty and owl:equivalentClass to the set of terms for the vocab expansion
15:39:50 [ivan]: ack gkellogg
15:40:13 [gkellogg]: gkellogg: concerned that it adds a greater burden if we don't replace rdfs:subClassOf, etc.
15:40:57 [gkellogg]: ivan: we can't remove the others.
15:41:47 [gkellogg]: niklasl: OWL does build on RDFS.
15:41:53 [ivan]: +1
15:41:55 [niklasl]: +1
15:41:57 [gkellogg]: +1
15:42:02 [ShaneM]: +1
15:42:11 [ivan]: RESOLVED: add owl:equivalentProperty and owl:equivalentClass to the set of terms for the vocab expansion
15:42:12 [tomayac]: n/a
15:42:26 [gkellogg]: ivan: already made a version on the core document, and will CVS commit it.
15:42:53 [gkellogg]: … instead of referring to RDFS entailment, refer to OWL ruleset.
15:43:08 [gkellogg]: q+
15:43:14 [ivan]: ack gkellogg
15:43:55 [gkellogg]: gkellogg: need to figure out how to deal with optional tests for these issues.
15:44:15 [gkellogg]: shanem: the whole is option, implement all or none.
15:44:30 [ivan]: ISSUE-118?
15:44:30 [trackbot]: ISSUE-118 -- Should we consider allowing the '/' character in a term -- open
15:44:30 [trackbot]: http://www.w3.org/2010/02/rdfa/track/issues/118
15:45:13 [gkellogg]: ivan: "term" defined as NCNAME, meaning that it must begin with a apha char and can't have a '/'.
15:45:19 [gkellogg]: s/apha/alpha/
15:45:21 [ShaneM]: NCTERM is a simple term definintion that does not allow a colon
15:45:23 [ShaneM]: NC == No Colon
15:45:46 [gkellogg]: ivan: propose to allow both a number as a first character and a '/'
15:45:58 [gkellogg]: shanem: can have a number with NCNAME, just not an ID.
15:46:03 [ShaneM]: vocab=foo
15:46:11 [ShaneM]: property='shane'
15:46:17 [ShaneM]: vocab="foo#'
15:46:24 [ShaneM]: foo#shane
15:46:30 [ShaneM]: foo#123shane
15:46:54 [gkellogg]: shanem: can't dereference foo:123shane
15:47:02 [gkellogg]: s/:/#/
15:47:07 [niklasl]: q+
15:47:13 [gkellogg]: ivan: so issue is, can we allow a '/'
15:47:13 [ivan]: ack niklasl
15:47:24 [gkellogg]: niklasl: but not as the first character
15:47:59 [gkellogg]: … can an identifier (NCNAME) begin with a '/'?
15:48:04 [gkellogg]: shanem: can't have one at all.
15:48:09 [niklasl]: .. fragment identifer
15:48:17 [gkellogg]: ivan: we're talking about a term which is concatenated.
15:48:33 [niklasl]: .. vocab="foo#term-"
15:48:42 [gkellogg]: … vocab="foo", term="/shane" get "foo/shane".
15:48:57 [gkellogg]: … don't see this as an important use case, but don't see why it should be restricted.
15:49:01 [ShaneM]: I have no objection to allowing a slash, but not as the first character....q+ to talk about restrictions
15:50:02 [gkellogg]: shanem: we don't have ambiguity now because of datatype restrictions. We only use terms with absURI or CURIE.
15:50:38 [gkellogg]: niklasl: thinking about problems with JSON-LD which may come up here in RDFa.
15:50:43 [ivan]: PROPOSAL: allow '/' character to appear in a term, except for the first character
15:50:55 [niklasl]: +1
15:50:58 [ivan]: +1
15:51:00 [gkellogg]: +1
15:51:02 [scor]: +1
15:51:04 [tomayac]: +1
15:51:14 [MacTed]: +2
15:51:20 [ivan]: RESOLVED: allow '/' character to appear in a term, except for the first character
15:51:20 [ShaneM]: +1
15:51:24 [MacTed]: s/2/1/
15:51:25 [MacTed]: :-)
15:51:44 [gkellogg]: ivan: will commit changes on document with OWL terms. Shane, can you make this change?
15:52:13 [gkellogg]: ivan: high-hanging fruit ...
15:52:18 [ivan]: Topic: link relations
15:52:23 [ivan]: ISSUE-108?
15:52:23 [trackbot]: ISSUE-108 -- Refine/deprecate Link relations for the RDFa 1.1 Default Profile. -- open
15:52:23 [trackbot]: http://www.w3.org/2010/02/rdfa/track/issues/108
15:52:46 [gkellogg]: ivan: we had the discussion a few weeks ago and thought we had resolved it.
15:53:27 [gkellogg]: … IANA seemed reasonable, since then, information is that HTML5 decided not to use it, but instead they rely on the Microformat Wiki.
15:53:44 [gkellogg]: … this makes the list changeable and relatively uncontrolled.
15:53:49 [gkellogg]: q+
15:54:15 [ivan]: ack gkellogg
15:54:17 [gkellogg]: … must revisit decision. My feeling is to drop link relations altogether.
15:55:17 [gkellogg]: gkellogg: I'd drop them too.
15:55:18 [niklasl]: q+
15:55:50 [gkellogg]: shanem: I don't appreciate the concern about the potential difference between HTML5's and our own. We should continue to use our existing definitions.
15:56:07 [ivan]: ack niklasl
15:56:09 [gkellogg]: … Wiki and IANA solve a non-problem.
15:56:25 [gkellogg]: niklasl: worried about creative commons use of license.
15:56:59 [gkellogg]: ivan: we previously raised with ben, as people commonly use "cc:" prefix. (not too sure, though).
15:57:12 [gkellogg]: … CC encourages the use of prefixes and CURIEs.
15:57:51 [gkellogg]: ivan: can't push through a resolution now.
15:58:12 [gkellogg]: … general sense is agreement, but shanem is not in favor of this.
15:58:28 [gkellogg]: … can't push for a resolution at the top of the hour.
15:58:46 [gkellogg]: niklasl: expressed questions on the mailing list.
15:58:55 [gkellogg]: ivan: continue discussion on the mailing list.
15:59:38 [gkellogg]: ivan: open issues, @href content model of URL
15:59:47 [gkellogg]: … <head> and <body> issues.
15:59:59 [gkellogg]: … replace @about with @resource in RDFa Lite
16:00:02 [gkellogg]: … Link Relations.
16:00:34 [gkellogg]: … These seem to be remaining issues. Suggest that we try to reach equilibrium on mailing list so that we can make an easy decision.
16:00:50 [gkellogg]: … We should publish a draft in Dec. that resolves these issues.
16:01:13 [gkellogg]: ivan: no meeting next week.
16:02:06 [Zakim]: -gkellogg
16:02:08 [Zakim]: -MacTed
16:02:10 [Zakim]: -scor
16:02:12 [Zakim]: -niklasl
16:02:16 [Zakim]: -ShaneM
16:02:20 [Zakim]: SW_RDFa()10:00AM has ended
16:02:26 [Zakim]: Attendees were Ivan, ShaneM, gkellogg, scor, MacTed, niklasl
16:02:29 [ivan]: rrsagent, draft minutes
16:02:29 [RRSAgent]: I have made the request to generate http://www.w3.org/2011/11/17-rdfa-minutes.html ivan
16:12:03 [niklasl]: niklasl has left #rdfa
16:53:50 [ShaneM]: ShaneM has left #rdfa
17:04:07 [MacTed]: RRSAgent, make logs public
17:04:22 [MacTed]: trackbot, end meeting
17:04:22 [trackbot]: Zakim, list attendees
17:04:23 [trackbot]: RRSAgent, please draft minutes
17:04:23 [RRSAgent]: I have made the request to generate http://www.w3.org/2011/11/17-rdfa-minutes.html trackbot
17:04:24 [trackbot]: RRSAgent, bye
17:04:24 [RRSAgent]: I see 2 open action items saved in http://www.w3.org/2011/11/17-rdfa-actions.rdf :
17:04:24 [RRSAgent]: ACTION: fold into HTML5 document anything relevant from these minutes [1]
17:04:24 [RRSAgent]: recorded in http://www.w3.org/2011/11/17-rdfa-irc#T15-23-22
17:04:24 [RRSAgent]: ACTION: manu1 to resolve to implement 97 and 113 [2]
17:04:24 [RRSAgent]: recorded in http://www.w3.org/2011/11/17-rdfa-irc#T15-36-59