Chatlog 2012-05-10

From RDFa Working Group Wiki
Jump to: navigation, search

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

13:07:09 <RRSAgent> RRSAgent has joined #rdfa
13:07:09 <RRSAgent> logging to
13:07:10 <trackbot> RRSAgent, make logs world
13:07:10 <Zakim> Zakim has joined #rdfa
13:07:12 <trackbot> Zakim, this will be 7332
13:07:12 <Zakim> ok, trackbot; I see SW_RDFa()10:00AM scheduled to start in 53 minutes
13:07:13 <trackbot> Meeting: RDF Web Applications Working Group Teleconference
13:07:14 <trackbot> Date: 10 May 2012
13:19:03 <danbri> danbri has joined #rdfa
13:38:41 <danbri> danbri has joined #rdfa
13:49:04 <ShaneM> ShaneM has joined #rdfa
13:49:15 <ShaneM> ShaneM has left #rdfa
13:55:42 <niklasl> niklasl has joined #rdfa
14:00:24 <Zakim> SW_RDFa()10:00AM has now started
14:00:31 <Zakim> +??P8
14:00:34 <niklasl> zakim, I am ??P8
14:00:34 <Zakim> +niklasl; got it
14:00:48 <ShaneM> ShaneM has joined #rdfa
14:01:07 <Zakim> +??P14
14:01:09 <Zakim> -niklasl
14:01:09 <manu1> zakim, I am ??P14
14:01:11 <Zakim> +niklasl
14:01:13 <Zakim> +??P13
14:01:17 <Zakim> +manu1; got it
14:01:17 <gkellogg> zakim, I am ??P13
14:01:20 <Zakim> +gkellogg; got it
14:01:31 <ivan> zakim, dial ivan-voip
14:01:31 <Zakim> ok, ivan; the call is being made
14:01:32 <Zakim> +Ivan
14:02:12 <Zakim> +??P16
14:02:20 <ShaneM> zakim, ??P16 is ShaneM
14:02:20 <Zakim> +ShaneM; got it
14:06:43 <manu1> Agenda:
14:06:43 <manu1> Guest: Dan (danbri) Brickley
14:06:56 <manu1> scribenick: manu1
14:09:29 <manu1> Topic: RDFa Community Review
14:10:00 <manu1> ivan: Transition to Proposed Recommendation went well... 
14:10:23 <ivan>
14:10:51 <manu1> manu: The launch of went very well - lots of traffic on the #rdfa twitter feed yesterday.
14:11:24 <manu1> manu: We have one one more big release today... in a couple of hours.
14:12:23 <manu1> manu: What else do we have to do for the PR, Ivan? Contact W3C members?
14:12:40 <manu1> ivan: Yes, we should contact members to make sure that they know that the RDFa 1.1 vote is happening.
14:13:27 <manu1> gkellogg: How does the voting work? Threshold?
14:13:50 <manu1> 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 <manu1> 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 <manu1> ivan: At our AC meeting - I'll ask for votes.
14:17:14 <manu1> shane: The PF WG care about this as well ... they will vote.
14:18:04 <manu1> manu: I'll get an e-mail to you with all the folks we want to contact.
14:18:26 <manu1> 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 <manu1> 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 <manu1> ivan: That is the /TR/rdf-syntax/ link should re-direct.
14:19:48 <manu1> manu: Is that standard procedure?
14:20:10 <manu1> shane: pretty standard, yes - new docs "supersede" old ones.
14:20:21 <manu1> Topic: ISSUE-135: RDFa Lite and non-RDFa @rel values
14:20:29 <manu1>
14:21:03 <manu1> ivan: There are two things that are still up in the air with this issue...
14:21:29 <manu1> niklasl: The two options listed in the issue tracker doesn't list all of the options... stephane sent an update.
14:22:58 <manu1> 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 <manu1> ivan: obviously, the second one is much simpler.
14:23:39 <niklasl> q+
14:23:42 <manu1> 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 <manu1> ivan: The other one has minimum impact, but is harder to explain to those not steeped in this stuff.
14:24:07 <gkellogg> q+
14:24:08 <manu1> ivan: The second one would mean that rel="license" wouldn't work.
14:24:12 <manu1> ack niklasl
14:24:45 <manu1> 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 <danbri> ( rel=author is worth bearing in mind, e.g. )
14:25:18 <manu1> 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 <manu1> 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 <manu1> 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 <manu1> niklasl: Both of them don't seem to relate at all to the subject matter... so the situation is pretty deep.
14:27:52 <manu1> niklasl: I am still in favor of option #1 - rel="license" are important...
14:28:06 <manu1> manu: Dan Brickley (above) also says that rel="author" is important as well.
14:28:38 <manu1> 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 <manu1> 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 <manu1> ack gkellogg
14:30:13 <manu1> 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 <manu1> gkellogg: It might be that we want to include terms that are defined in the default context, but not apply @vocab.
14:30:38 <manu1> niklasl: Yes, agreed.
14:31:38 <manu1> 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 <manu1> gregg: We would add terms like license and author.
14:34:08 <manu1> 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 <manu1> 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 <manu1> 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 <manu1> 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 <manu1> 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 <manu1> ivan: Yes, these are issues... but we can't really do anything about it.
14:40:38 <niklasl> * 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 <manu1> ivan: That's option #1
14:41:01 <manu1> niklasl: That's what danbri said he liked...
14:41:13 <manu1> ivan: I think the simpler one is option #2.
14:41:23 <manu1> niklasl: I think if we do option #2 with the pre-defined terms, that's okay as well.
14:41:45 <danbri> I'm not sure what I like really! it's hard to judge consequences, sorry :/
14:42:02 <manu1> 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 <manu1> manu: I agree with the sentiment...
14:42:35 <manu1> niklasl: I'm concerned that option #2 is a bit heavy-handed.
14:43:14 <ivan> 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 <manu1> 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 <manu1> 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 <manu1> manu: This applies for @rev as well.
14:45:48 <manu1> 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 <niklasl> .. Compare: <a property="url" href="abc" rel="license">, <a property="url" href="abc" rel="nofollow"> and <a property="url" href="abc" rel="sweetheart">
14:45:59 <manu1> ivan: We can add terms after discussing it at any time.
14:47:58 <manu1> Discussion about what happens with niklasl's markup above based on the proposals on the table.
14:49:04 <manu1> 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 <manu1> niklasl: The problem with option #2 - is that markup could change over time because new terms are added... 
14:50:40 <manu1> 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 <manu1> niklasl: We could say "@property is /stronger/ than @rel in HTML5"
14:51:41 <manu1> 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 <manu1> manu: Too radical - we don't want to do that.
14:52:11 <manu1> niklasl: It would also be a b/c issue.
14:53:32 <danbri_> danbri_ has joined #rdfa
14:53:33 <Zakim> -niklasl
14:54:04 <Zakim> +??P8
14:54:08 <niklasl> zakim, I am ??p8
14:54:08 <Zakim> +niklasl; got it
14:54:54 <manu1> niklasl: We're trying to find something easier to explain.
14:55:51 <Zakim> + +1.415.459.aaaa
14:56:04 <gkellogg> zakim, I am aaaa
14:56:05 <Zakim> +gkellogg; got it
14:56:34 <Zakim> -gkellogg
14:57:16 <MacTed> MacTed has joined #rdfa
14:57:57 <manu1> 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 <manu1> 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 <manu1> manu: So, I'm leaning toward option #1 now.
15:00:32 <ivan> 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 <ShaneM> then the processor must act as if the attribute is not present
15:01:55 <niklasl> * If @property is present and @rel only contains terms (that is,
15:01:56 <niklasl> keywords without any colon, ":"), @rel MUST be ignored and the
15:01:56 <niklasl> processor behave as if @rel is not present.
15:03:38 <manu1> 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 <niklasl> +1
15:03:47 <ivan> +1
15:03:48 <manu1> manu: +1
15:03:52 <gkellogg> +1
15:04:31 <niklasl> .. <a property="url" href="abc" rel="license">
15:05:35 <ShaneM> +1
15:05:40 <manu1> 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 <niklasl> @danbri, does this sound good too you?
15:06:42 <manu1> Topic: ISSUE-137: HTML+RDFa should normatively declare media types and describe how to identify relative to XHTML+RDFa 1.1
15:07:00 <manu1> 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 <manu1> shanem: HTML5 says something about this explicitly.
15:07:26 <manu1> ivan: HTML5+RDFa should not declare media types... 
15:07:54 <manu1> gkellogg: Which profile should be used - that we don't state it makes it sound confusing to Alex... 
15:08:01 <manu1> shanem: We already say this in the XHTML spec.
15:08:42 <ShaneM> 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 <manu1> manu: Follow your nose is clear on this - it's "text/html" for HTML5... and "application/xhtml+xml" for XHTML5.
15:09:14 <manu1> gkellogg: I think that people will still wrongly understand the difference between XHTML1 and XHTML5.
15:09:20 <manu1> gkellogg: I think some clarification would be good.
15:09:42 <manu1> ivan: This is not our mess, right?
15:10:39 <manu1> shanem: I think you're reading more into it than you need to... we already say this for XHTML+RDFa.
15:10:49 <manu1> manu: I think we do need to say something non-normative to be clear about this... 
15:10:52 <manu1> niklasl: I agree.
15:11:15 <manu1> 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 <manu1> 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 <gkellogg> +1
15:12:34 <manu1> manu: +1
15:12:35 <ivan> +1
15:12:36 <niklasl> +1
15:13:03 <ShaneM> +1
15:14:08 <manu1> 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 <manu1> manu: The specs already say this...
15:15:02 <manu1> Topic: ISSUE-140: Support for @data attribute
15:15:55 <manu1>
15:16:50 <niklasl> q+
15:16:54 <manu1> manu: Should we add @data? Does data act like @src if we add it? 
15:17:08 <manu1> shanem: We don't do this in XHTML, we shouldn't do it for HTML5.
15:17:40 <manu1> gregg: This comes out of the Microdata processing model - we would do this to track Microdata.
15:17:52 <manu1> ivan: Don't we also have a data element in HTML5?
15:18:01 <manu1> gkellogg: That is different... this would only be allowed on OBJECT.
15:18:12 <manu1> shanem: This is in HTML4 as well - it's not new.
15:18:33 <manu1> shanem: This is also weird - it's not relative to BASE, it's interpreted relative to code_base.
15:18:50 <manu1> shanem: I can see why we /might/ want to process it, if it's super-important we could do it.
15:18:57 <manu1> ack niklasl
15:19:19 <manu1> manu: It's used for Flash, right?
15:19:30 <manu1> shanem: OBJECT was supposed to replace image... because it has fallback.
15:20:06 <manu1> gkellogg: i'm fine with us not supporting this as well.
15:20:22 <manu1> manu: I don't think we should support it either... it's on its way out.
15:20:46 <manu1> PROPOSAL: Do not support the @data attribute on the OBJECT element in HTML+RDFa.
15:20:48 <manu1> manu: +1
15:20:52 <ShaneM> +1
15:20:53 <ivan> +1
15:20:54 <gkellogg> +1
15:20:55 <niklasl> +1 (at this time)
15:20:58 <manu1> RESOLVED: Do not support the @data attribute on the OBJECT element in HTML+RDFa.
15:21:31 <manu1> Topic: HTML5 terms
15:21:41 <manu1> gkellogg: Do we want to add any new terms to HTML5 default context?
15:21:49 <manu1> manu: Let's wait to do that.
15:21:58 <manu1> ivan: Yes, we should wait - see how things progress in HTML WG.
15:22:03 <manu1> niklasl: Put it on the wiki?
15:22:08 <manu1> ivan: Probably...
15:22:57 <manu1> ivan: I have already made an errata page - one page for all 3 specs.
15:22:57 <manu1> manu: Okay, that's it - all issues are resolved - we are DONE! (for now). We will meet again a week before REC, and then again to finalize the RDF API and RDFa API work.
15:23:08 <Zakim> -ShaneM
15:25:35 <Zakim> -Ivan