13:07:09 RRSAgent has joined #rdfa 13:07:09 logging to http://www.w3.org/2012/05/10-rdfa-irc 13:07:10 RRSAgent, make logs world 13:07:10 Zakim has joined #rdfa 13:07:12 Zakim, this will be 7332 13:07:12 ok, trackbot; I see SW_RDFa()10:00AM scheduled to start in 53 minutes 13:07:13 Meeting: RDF Web Applications Working Group Teleconference 13:07:14 Date: 10 May 2012 13:07:44 ivan has changed the topic to: Meeting Agenda, May 10, http://www.w3.org/mid/4FAB19D4.9090907@digitalbazaar.com 13:19:03 danbri has joined #rdfa 13:38:41 danbri has joined #rdfa 13:49:04 ShaneM has joined #rdfa 13:49:15 ShaneM has left #rdfa 13:54:12 rdfa has joined #rdfa 13:54:12 [rdfa-website] msporny pushed 1 new commit to master: https://github.com/rdfa/rdfa-website/commit/48f308e87db9608510d5178e567d651905e3cd8c 13:54:12 [rdfa-website/master] Made public domain license explicit in the README.markdown file. - Manu Sporny 13:54:13 rdfa has left #rdfa 13:54:24 manu++ 13:55:42 niklasl has joined #rdfa 13:56:04 thanks, I'll relay that 13:58:32 thanks! I've passed it on 14:00:24 SW_RDFa()10:00AM has now started 14:00:31 +??P8 14:00:34 zakim, I am ??P8 14:00:34 +niklasl; got it 14:00:48 ShaneM has joined #rdfa 14:01:07 +??P14 14:01:09 -niklasl 14:01:09 zakim, I am ??P14 14:01:11 +niklasl 14:01:13 +??P13 14:01:17 +manu1; got it 14:01:17 zakim, I am ??P13 14:01:20 +gkellogg; got it 14:01:31 zakim, dial ivan-voip 14:01:31 ok, ivan; the call is being made 14:01:32 +Ivan 14:02:12 +??P16 14:02:20 zakim, ??P16 is ShaneM 14:02:20 +ShaneM; got it 14:06:43 Agenda: http://lists.w3.org/Archives/Public/public-rdfa-wg/2012May/0040.html 14:06:56 scribenick: manu1 14:07:20 http://rdf.greggkellogg.net/distiller?format=turtle&in_fmt=microdata&uri=https://github.com/gkellogg/rdf-microdata 14:09:29 Topic: RDFa Community Review 14:10:00 ivan: Transition to Proposed Recommendation went well... 14:10:23 http://www.w3.org/blog/SW/2012/05/08/three-rdfa-specifications-are-proposed-recommendations/ 14:10:51 manu: The launch of http://rdfa.info/ went very well - lots of traffic on the #rdfa twitter feed yesterday. 14:11:24 manu: We have one one more big release today... in a couple of hours. 14:12:23 manu: What else do we have to do for the PR, Ivan? Contact W3C members? 14:12:40 ivan: Yes, we should contact members to make sure that they know that the RDFa 1.1 vote is happening. 14:13:27 gkellogg: How does the voting work? Threshold? 14:13:50 ivan: No hard figure, not cast in concrete - if there is a Proposed REC that only gets 2-3 votes - then we would say that there probably isn't a large backing of the spec... 14:14:29 ivan: we're looking for wider acceptance of the spec - 8-10 positive votes would mean no problem... large companies are even better. 14:16:22 ivan: At our AC meeting - I'll ask for votes. 14:17:14 shane: The PF WG care about this as well ... they will vote. 14:18:04 manu: I'll get an e-mail to you with all the folks we want to contact. 14:18:26 ivan: We should make sure the RECs are ready - I will be on the road during the last days of the PR period. 14:19:06 ivan: At some point, the header of the final document should be updated - old spec should re-direct to the new one - do it for the old REC. 14:19:25 ivan: That is the /TR/rdf-syntax/ link should re-direct. 14:19:48 manu: Is that standard procedure? 14:20:10 shane: pretty standard, yes - new docs "supersede" old ones. 14:20:21 Topic: ISSUE-135: RDFa Lite and non-RDFa @rel values 14:20:29 http://www.w3.org/2010/02/rdfa/track/issues/135 14:21:03 ivan: There are two things that are still up in the air with this issue... 14:21:29 niklasl: The two options listed in the issue tracker doesn't list all of the options... stephane sent an update. 14:22:58 ivan: I think we are converging toward two possibilities 1) If you have an element that has both @rel and @property in HTML5, then the @rel can only take CURIEs, which will result in things like rel="nofollow" being ignored, then 2) There is a more global one that in HTML5+RDFa a @rel value can only have CURIEs. 14:23:05 ivan: obviously, the second one is much simpler. 14:23:39 q+ 14:23:42 ivan: In HTML5, @rel is used in a fairly uncontrolled manner with a bunch of values that don't really have any semantic meaning to the document. It's a clear story, but with some down-sides. 14:23:57 ivan: The other one has minimum impact, but is harder to explain to those not steeped in this stuff. 14:24:07 q+ 14:24:08 ivan: The second one would mean that rel="license" wouldn't work. 14:24:12 ack niklasl 14:24:45 niklasl: That sums it up. Although, it wasn't entirely clear with option #2 that @rel in HTML5 could only contain CURIEs, or if it didn't care about @vocab, so it could take pre-defined terms. 14:24:55 ( rel=author is worth bearing in mind, e.g. http://googlewebmastercentral.blogspot.com/2011/06/authorship-markup-and-web-search.html ) 14:25:18 ivan: No, the problem comes with what we call the "Stephane" phenomenon - CMS systems that auto-inject things like rel="nofollow" corrupts the author's intent. 14:26:11 niklasl: Yes, important point - @rel has been used for semantic stuff for a long time... since RDFa 1.0 - @vocab has changed the situation. Given that @vocab is set to nothing by default... option #2 is the "default state". The issue is whether that endangers RDFa Lite 1.1. 14:27:14 niklasl: Given what I see, if somebody uses @rel="license" @rel="author" or anything that relates to the @href... I would argue that it's very much inline with RDFa - with terms as well - and what Stephane highlighted is that @rel is also used in some cases, orthogonally to the subject matter, with mechanical annotions. The only ones that we know are problems are nofollow and prefetch. 14:27:30 niklasl: Both of them don't seem to relate at all to the subject matter... so the situation is pretty deep. 14:27:52 niklasl: I am still in favor of option #1 - rel="license" are important... 14:28:06 manu: Dan Brickley (above) also says that rel="author" is important as well. 14:28:38 niklasl: With @vocab you can choose which vocab you use - so, if you want to use nofollow and not generate garbage triples, you can always use vocab="" 14:29:32 niklasl: It requires awareness, for this reason, option #1 is a heuristic... if you use RDFa Lite 1.1 and want to use property... any @rel attribute using a term would be 'muted' by the use of property. @rel is a double-edged sword in HTML5. 14:29:39 ack gkellogg 14:30:13 gkellogg: The advantage of option #2 is that it is really clear what it means - we might want to consider amending it to include explicitly defined terms in the default context - rel=license and rel=author would be two of those. 14:30:33 gkellogg: It might be that we want to include terms that are defined in the default context, but not apply @vocab. 14:30:38 niklasl: Yes, agreed. 14:31:38 ivan: Conceptually, what Gregg is saying: if I see a @rel, if the term is one of the pre-defined ones - I use the corresponding URIs, otherwise I ditch it. 14:32:17 gregg: We would add terms like license and author. 14:34:08 niklasl: If somebody uses XHTML1.1 instead of XHTML5, the meaning would change in some cases... because the terms between the two languages are different... 14:34:59 ivan: Yes, right and wrong at the same time - theoretically that is true, but in practice, we don't have too many XHTML1.1 documents that use @rel together with @vocab - because @vocab is brand new. 14:35:41 ivan: No big changes for old documents... out of the loads of @rel values - only a few - like license has meaning... stylesheet has always been considered junk. 14:39:33 manu: I think people are going to have a hard time accepting that there are differences between XHTML1 and XHTML5 documents if they use certain terms... but they are different languages... but authors are not going to care about that. It's a concern... 14:39:56 manu: I don't know if there is much that we can do about that - as this is the right thing to do... the meaning of terms changed between XHTML1 and HTML5... 14:40:18 ivan: Yes, these are issues... but we can't really do anything about it. 14:40:38 * If @property is present and @rel only contains terms (that is, keywords without any colon, ":"), @rel MUST be ignored and the processor behave as if @rel is not present. 14:40:52 ivan: That's option #1 14:41:01 niklasl: That's what danbri said he liked... 14:41:13 ivan: I think the simpler one is option #2. 14:41:23 niklasl: I think if we do option #2 with the pre-defined terms, that's okay as well. 14:41:45 I'm not sure what I like really! it's hard to judge consequences, sorry :/ 14:42:02 niklasl: I want to bring the control that people have with vocab a bit tighter - I'm wavering on this because I might be trying to salvage an unsalvage-able situation. 14:42:18 manu: I agree with the sentiment... 14:42:35 niklasl: I'm concerned that option #2 is a bit heavy-handed. 14:43:14 PROPOSED: for the usage of @rel in HTML5+RDFa: if the value of @rel is one of the predefined terms in the initial context, then the corresponding URI is used, if the value is another term (non-curie or non-URI) then it is ignored; if the value of @rel becomes empty after these steps then @rel itself is ignored altogether 14:44:11 niklasl: We have to make sure that option #2 is defined in such a way that if @rel doesn't contained CURIEs, it is ignored altogether... will readers understand that? 14:44:31 ivan: We will write it in a way that is understandable - if you want to use @rel for RDFa purposes, either use CURIEs or use the pre-defined values. 14:45:10 manu: This applies for @rev as well. 14:45:48 ivan: I think the message is relatively clear - we can have discussions on whether or not we need more than license, author, role, seeAlso, etc. 14:45:51 .. Compare: , and 14:45:59 ivan: We can add terms after discussing it at any time. 14:47:58 Discussion about what happens with niklasl's markup above based on the proposals on the table. 14:49:04 gkellogg: We need a warning in the spec that we suggest that authors don't mix rel and property on the same element in HTML5. 14:49:59 niklasl: The problem with option #2 - is that markup could change over time because new terms are added... 14:50:40 ivan: I agree - we're in a situation where anything that we do is wrong - if we leave it alone it's wrong, if we do option #1 it's wrong, if we do option #2, it's wrong... lesser evils... the problem is trying to explain this to someone easily. 14:50:56 niklasl: We could say "@property is /stronger/ than @rel in HTML5" 14:51:41 ivan: We could say that we not only discourage @property and @rel on the same element, but in HTML5+RDFa - we remove any @rel if it is used together with @property. 14:51:59 manu: Too radical - we don't want to do that. 14:52:11 niklasl: It would also be a b/c issue. 14:53:32 danbri_ has joined #rdfa 14:53:33 -niklasl 14:54:04 +??P8 14:54:08 zakim, I am ??p8 14:54:08 +niklasl; got it 14:54:54 niklasl: We're trying to find something easier to explain. 14:55:51 + +1.415.459.aaaa 14:56:04 zakim, I am aaaa 14:56:05 +gkellogg; got it 14:56:34 -gkellogg 14:57:16 MacTed has joined #rdfa 14:57:57 manu: I don't think that option #1 isn't that hard to teach - don't use @property and @rel on the same element. If you do, @property will win in @rel doesn't contain a full IRI or CURIE. 14:58:29 manu: I think we need to address Stephane's issue, but not go too far and change how it's processed too greatly. 14:58:52 manu: So, I'm leaning toward option #1 now. 15:00:32 PROPOSED: if @property and @rel/@rev are on the same elements, the non-CURIE and non-URI @rel/@rev values are, conceptually, removed. If, after this, the value of @rel/@rev becomes empty, then the attribute is removed altogether 15:01:40 then the processor must act as if the attribute is not present 15:01:55 * If @property is present and @rel only contains terms (that is, 15:01:56 keywords without any colon, ":"), @rel MUST be ignored and the 15:01:56 processor behave as if @rel is not present. 15:03:38 PROPOSAL: If @property and @rel/@rev are on the same elements, the non-CURIE and non-URI @rel/@rev values are ignored. If, after this, the value of @rel/@rev becomes empty, then the then the processor must act as if the attribute is not present. 15:03:43 +1 15:03:47 +1 15:03:48 +1 15:03:52 +1 15:04:31 .. 15:05:35 +1 15:05:40 RESOLVED: If @property and @rel/@rev are on the same elements, the non-CURIE and non-URI @rel/@rev values are ignored. If, after this, the value of @rel/@rev becomes empty, then the then the processor must act as if the attribute is not present. 15:06:02 @danbri, does this sound good too you? 15:06:42 Topic: ISSUE-137: HTML+RDFa should normatively declare media types and describe how to identify relative to XHTML+RDFa 1.1 15:07:00 ivan: This is a very messy situation that we're not in a position to solve - that is it's up to HTML5 15:07:07 shanem: HTML5 says something about this explicitly. 15:07:26 ivan: HTML5+RDFa should not declare media types... 15:07:54 gkellogg: Which profile should be used - that we don't state it makes it sound confusing to Alex... 15:08:01 shanem: We already say this in the XHTML spec. 15:08:42 we say: XHTML+RDFa documents should be labeled with the Internet Media Type "application/xhtml+xml" as defined in [RFC3236]. For further information on using media types with XHTML Family markup languages, see the informative note [XHTML-MEDIA-TYPES]. 15:08:46 manu: Follow your nose is clear on this - it's "text/html" for HTML5... and "application/xhtml+xml" for XHTML5. 15:09:14 gkellogg: I think that people will still wrongly understand the difference between XHTML1 and XHTML5. 15:09:20 gkellogg: I think some clarification would be good. 15:09:42 ivan: This is not our mess, right? 15:10:39 shanem: I think you're reading more into it than you need to... we already say this for XHTML+RDFa. 15:10:49 manu: I think we do need to say something non-normative to be clear about this... 15:10:52 niklasl: I agree. 15:11:15 niklasl: I expect some kind of HTML5 flavor - everything will be treated as that in the future - unless it's apparent in DOCTYPE or version that it isn't HTML5. 15:12:15 PROPOSAL: Add non-normative text to the HTML+RDFa specification that makes it clear which media types apply to the specification and under what circumstances documents should be processed according to the specification. 15:12:33 +1 15:12:34 +1 15:12:35 +1 15:12:36 +1 15:13:03 +1 15:14:08 RESOLVED: Add non-normative text to the HTML+RDFa specification that makes it clear which media types apply to the specification and under what circumstances documents should be processed according to the specification. 15:14:19 manu: The specs already say this... 15:15:02 Topic: ISSUE-140: Support for @data attribute 15:15:55 https://www.w3.org/2010/02/rdfa/track/issues/140 15:16:50 q+ 15:16:54 manu: Should we add @data? Does data act like @src if we add it? 15:17:08 shanem: We don't do this in XHTML, we shouldn't do it for HTML5. 15:17:40 gregg: This comes out of the Microdata processing model - we would do this to track Microdata. 15:17:52 ivan: Don't we also have a data element in HTML5? 15:18:01 gkellogg: That is different... this would only be allowed on OBJECT. 15:18:12 shanem: This is in HTML4 as well - it's not new. 15:18:33 shanem: This is also weird - it's not relative to BASE, it's interpreted relative to code_base. 15:18:50 shanem: I can see why we /might/ want to process it, if it's super-important we could do it. 15:18:57 ack niklasl 15:19:19 manu: It's used for Flash, right? 15:19:30 shanem: OBJECT was supposed to replace image... because it has fallback. 15:20:06 gkellogg: i'm fine with us not supporting this as well. 15:20:22 manu: I don't think we should support it either... it's on its way out. 15:20:46 PROPOSAL: Do not support the @data attribute on the OBJECT element in HTML+RDFa. 15:20:48 +1 15:20:52 +1 15:20:53 +1 15:20:54 +1 15:20:55 +1 (at this time) 15:20:58 RESOLVED: Do not support the @data attribute on the OBJECT element in HTML+RDFa. 15:21:31 Topic: HTML5 terms 15:21:41 gkellogg: Do we want to add any new terms to HTML5 default context? 15:21:49 manu: Let's wait to do that. 15:21:58 ivan: Yes, we should wait - see how things progress in HTML WG. 15:22:03 niklasl: Put it on the wiki? 15:22:08 ivan: Probably... 15:22:57 ivan: I have already made an errata page - one page for all 3 specs. 15:23:08 -ShaneM 15:25:35 -Ivan 15:30:17 -manu1 15:30:20 -gkellogg.a 15:30:21 -niklasl 15:30:21 SW_RDFa()10:00AM has ended 15:30:21 Attendees were niklasl, manu1, gkellogg, Ivan, ShaneM, +1.415.459.aaaa 15:31:24 niklasl has left #rdfa 15:32:59 ShaneM has joined #rdfa 16:35:43 ShaneM has left #rdfa 16:54:28 http://lists.w3.org/Archives/Public/public-rdfa/2012May/0000.html 16:54:43 anyone care to help move DCMI to publish rdfs in rdfa? 16:55:20 Sure, I'd be happy to work with them. 16:57:29 excellent! 16:58:00 you should be able to do a test build easily enough 16:58:20 I'll spend some time on it. 16:58:53 thanks :) ping me here or mail (or skype:danbrickley) if i can help 17:01:29 tbaker has joined #rdfa 17:01:49 tbaker, meet gkellogg & vice-versa 17:01:57 tbaker = tom baker, of dublin core 17:02:09 Hi Tom, let me know how I can help. 17:02:14 gkellogg, glad to meet you! 17:02:33 I'm Gregg, by the way. You should have my email in the response to Dan's email. 17:03:15 There are two github repositories. I will need to update one. I do not have access to the other, where Hugh Barnes started to add RDFa 17:03:38 That's the one I cloned on my local machine. 17:03:38 See https://github.com/hughbris/website for the partial RDFa fork; https://github.com/dublincore/website for the main branch. 17:03:53 I'll need to update dublincore 17:05:44 Do you want to stick with RDFa 1.0, or is 1.1 okay? 17:06:37 The generated doctype is for XHTML1+RDFa 1.0. Are you targeting XHTML1 or is XHTML5 appropriate for you now? I'd suggest HTML+RDFa 1.1 profile using XHTML5 17:09:38 1.1 would be cool 17:09:40 lite ideally 17:10:24 There are some uses of @datatype that may loose some accuracy. Otherwise, Lite should be okay. 17:10:59 can live w/out i think 17:12:01 rrsagent, bye 17:12:01 I see no action items