Chatlog 2011-11-10

From RDFa Working Group Wiki
Jump to: navigation, search

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

14:55:57 <RRSAgent> RRSAgent has joined #rdfa
14:55:57 <RRSAgent> logging to
14:55:59 <trackbot> RRSAgent, make logs world
14:56:00 <Zakim> Zakim has joined #rdfa
14:56:02 <trackbot> Zakim, this will be 7332
14:56:02 <Zakim> ok, trackbot; I see SW_RDFa()10:00AM scheduled to start in 4 minutes
14:56:04 <trackbot> Meeting: RDF Web Applications Working Group Teleconference
14:56:06 <trackbot> Date: 10 November 2011
14:56:41 <manu1> Agenda:
13:44:34 <manu1> Guest: Niklas (niklasl) Lindström
14:58:30 <niklasl> niklasl has joined #rdfa
15:00:42 <ShaneM> ShaneM has joined #rdfa
15:01:05 <Zakim> SW_RDFa()10:00AM has now started
15:01:17 <Zakim> +scor
15:01:31 <Zakim> +??P35
15:01:37 <ShaneM> zakim, I am ??P35
15:01:53 <Zakim> +ShaneM; got it
15:02:09 <Zakim> +??P41
15:02:12 <gkellogg> zakim, I am ??P41
15:02:15 <Zakim> +??P38
15:02:23 <Zakim> +??P42
15:02:25 <manu1> zakim, I am ??P38
15:02:41 <ivan> zakim, dial ivan-voip
15:02:50 <Zakim> +gkellogg; got it
15:03:15 <Zakim> +manu1; got it
15:03:23 <Zakim> -gkellogg
15:03:33 <Zakim> ok, ivan; the call is being made
15:03:37 <Zakim> +Ivan
15:03:40 <manu1> zakim, who is on the call?
15:04:01 <manu1> zakim, I am ??P41
15:04:03 <scor> zakim, who is making noise?
15:04:09 <Zakim> + +1.404.978.aaaa
15:04:20 <Zakim> +??P53
15:04:33 <niklasl> zakim, I am ??P53
15:04:36 <Zakim> On the phone I see scor, ShaneM, manu1, ??P42, Ivan, +1.404.978.aaaa, ??P53
15:04:54 <gkellogg> zakim, I'm ??P42
15:04:56 <Zakim> sorry, manu1, I do not see a party named '??P41'
15:05:02 <Zakim> scor, listening for 10 seconds I heard sound from the following: ShaneM (11%), ??P42 (29%), ??P53 (20%)
15:05:06 <Zakim> +niklasl; got it
15:05:20 <Zakim> I don't understand 'I'm ??P42', gkellogg
15:05:34 <gkellogg> zakim, I'm ??P42
15:05:36 <tomayac> zakim, +1.404.978.aaaa is me
15:05:41 <gkellogg> zakim, I am ??P42
15:05:53 <scor> zakim, ??P42 is gkellogg 
15:05:55 <Zakim> I don't understand 'I'm ??P42', gkellogg
15:05:57 <Zakim> +tomayac; got it
15:05:59 <Zakim> +gkellogg; got it
15:06:05 <Zakim> I already had ??P42 as gkellogg, scor
15:06:06 <tomayac> scribe: tomayac
15:06:14 <manu1> Agenda:
15:06:23 <Zakim> I don't understand 'fine then!', scor
15:06:30 <ivan> Topic: Link Relations and Microformats Community
15:06:30 <tomayac> ivan: It turns out that HTML5 uses the link relations defined by the Microformats community and not from the IETF Link Types registry, so using the Link Types from the IETF Link Types registry will conflict with the ones that are "officially recognized" by the HTML5 specification.
15:06:30 <ivan>
15:06:30 <ivan>
15:06:59 <tomayac> ivan: Just received an e-mail from Tantek (of Microformats community) verifying this - we will have to look at link relations again
15:07:21 <tomayac> ivan: I'm starting to doubt that the defaults specified by the Microformats community make sense.
15:07:05 <tomayac> ivan: …for link relations that is
15:07:32 <tomayac> ivan: I'll follow up on a related issue after the call
15:07:50 <manu1> Topic: Official support for RDFa Lite 1.1 and
15:07:52 <tomayac> Manu updates the group on the current feedback from, the proposed way forward, and the potential impact of the changes on adoption vs. backwards compatability.
15:07:54 <manu1>
15:20:09 <ShaneM> q+ to ask about publication process
15:20:28 <manu1> ack shaneM
15:20:28 <Zakim> ShaneM, you wanted to ask about publication process
15:23:01 <tomayac> ShaneM: Does our charter allow us to publish an RDFa Lite 1.1 specification?
15:23:03 <tomayac> ivan: Yes, I believe it does - we're chartered to publish RDFa 1.1 - we can do it as a single document or multiple documents.
15:23:07 <tomayac> ivan: In the very worst case, RDFa Lite 1.1 could become part of core, as a separate chapter - but we don't want to do that.
15:23:30 <tomayac> ShaneM: that seems like a workable option in the worst case.
15:23:44 <tomayac> ShaneM: We also need to publish a working draft of RDFa Core when we do a FPWD of RDFa Lite
15:24:12 <tomayac> manu: The vast majority of the WG is in favor of the property changes - there is only one dissenting opinion and that's from Toby, who hasn't been able to chat with us on the call yet and probably doesn't have the full picture. He does make a number of valid points, but we have discussed counter-points to those.
15:24:20 <tomayac> manu: The group seems to be in agreement of supporting the use case... let's make this an official WG decision.
15:24:39 <gkellogg> q+ to remind about "magnetic" @typeof
15:24:44 <tomayac> manu: we need two resolutions
15:25:00 <gkellogg> q-
15:25:28 <tomayac> ivan: There are two resolutions that should be separated.
15:25:52 <tomayac> ivan: my preference would be to publish Lite as a first public working draft
15:25:54 <niklasl> q+ to question the processing difference between @rel and "@href-attached" @property...
15:26:00 <tomayac> ivan: and then sort out the admin issue on pushing it forward towards REC - which is just an administrative issue, not something that should block our work here right now.
15:26:40 <tomayac> ivan: So, let's publish RDFa Lite, let's have the resolution
15:26:47 <tomayac> niklasl: we can discuss the technical details later
15:26:40 <tomayac> ivan: We have two inter-operable implementations so far that seem to work just fine, so we think this technical change is fine.
15:27:40 <ivan> PROPOSAL: Publish RDFa 1.1. Lite as a FPWD together with the next publication of RDFa 1.1 Core
15:28:11 <manu1> +1
15:28:26 <ivan> +1
15:28:28 <gkellogg> +1
15:28:29 <niklasl> +1
15:28:30 <tomayac> tomayac: +1
15:28:31 <scor> +1
15:28:35 <ShaneM> +1
15:28:38 <manu1> RESOLVED: Publish RDFa 1.1. Lite as a FPWD together with the next publication of RDFa 1.1 Core.
15:29:44 <tomayac> niklasl: quick question on order of publications, do we publish Lite and then Core, or Core and then Lite?
15:30:27 <tomayac> ivan: We publish both at the same time.
15:30:27 <tomayac> ivan: Ok, now - do we support the changes to the RDFa Core spec to support the use cases?
15:30:39 <manu1> PROPOSAL: Accept the modification proposal on the behaviour of @property and @typeof, as outlined in, modulo the technical details that still have to be sorted out, to support the use cases
15:30:54 <gkellogg> +1
15:30:55 <scor_> scor_ has joined #rdfa
15:30:55 <niklasl> +1
15:30:56 <manu1> +1
15:30:57 <ivan> +1
15:30:58 <tomayac> tomayac: +1
15:31:00 <scor_> +1
15:31:09 <ShaneM> +1
15:31:13 <manu1> RESOLVED: Accept the modification proposal on the behaviour of @property and @typeof, as outlined in, modulo the technical details that still have to be sorted out, to support the use cases.
15:32:55 <tomayac> manu: There are two additional changes to RDFa Lite that we need to discuss
15:33:06 <tomayac> manu: one is the addition of the @content attribute
15:33:21 <ivan> q+
15:33:31 <tomayac> manu: the other is to remove @rel from Lite, as it's not necessary for the or rnews use cases. People can use the newly changed property to support all of the use cases.
15:33:47 <gkellogg> q+ to ask about <data> @value as well
15:33:52 <tomayac> manu: I looked through all rnews and all markup, and we don't need @rel to support those use cases - let's simplify RDFa Lite even further.
15:34:09 <manu1> ack niklasl
15:34:10 <Zakim> niklasl, you wanted to question the processing difference between @rel and "@href-attached" @property...
15:35:20 <manu1> ack ivan
15:35:50 <tomayac> ivan: I think the content attribute in Lite should be allowed everywhere
15:36:30 <manu1> q+
15:36:48 <tomayac> ivan: to avoid unnecessary discussion I'd like to limit @content to just meta in RDFa Lite
15:37:03 <tomayac> ivan: concerning @rel, there are a few situations where it is necessary
15:37:17 <tomayac> ivan: I would not bind Lite exclusively to vocabularies like rnews and - we want a solution that is broader than that, right?
15:37:38 <tomayac> ivan: For some chaining use cases, we need @rel - like when you want to link on "foaf:knows" to multiple people.
15:38:06 <manu1> ack gkellogg
15:38:06 <Zakim> gkellogg, you wanted to ask about <data> @value as well
15:38:12 <tomayac> gkellogg: I don't think we want to over-complicate RDFa Lite - people seem to like the simplicity. 
15:38:13 <ShaneM> q+ to say ICK about elements
15:38:28 <manu1> +1 to what Gregg said!
15:39:30 <manu1> ack manu
15:39:35 <tomayac> gkellogg: @rel might be valid in a couple of use cases, but not worth adding it to Lite as we don't want to make Lite too complex. If people need @rel or @content, they can still use it and all RDFa processors will pick it up.
15:39:54 <tomayac> manu: I am in favor of what Gregg said - let's not put @rel and @content in RDFa Lite unless someone demands that it be added.
15:40:09 <tomayac> manu: the less it contains, the more powerful it is as an entry point for new authors
15:40:13 <scor_> I agree with gkellogg: the RDFa 1.1 Lite document should be as simple and straight forward as possible
15:40:23 <tomayac> manu: We want to send a clear message with RDFa Lite - RDFa is easy to use - you only need 3 attributes for the basic markup and 5 attributes if you want to name entities and do vocabulary mixing.
15:40:48 <tomayac> manu1: your @rel chaining use case is still possible with RDFa Lite, Ivan - you just do <div property="foaf:knows" typeof="foaf:Person"> for every person you want to link to. Yes, it's more markup than @rel... but that's why @rel is an advanced feature.
15:41:18 <tomayac> manu: Only three RDFa Lite attributes are necessary for most of the and rnews use cases - that's a pretty powerful message.
15:41:20 <manu1> ack ShaneM
15:41:20 <Zakim> ShaneM, you wanted to say ICK about elements
15:41:29 <tomayac> ShaneM: I don't mind removing @rel from the Lite doc
15:45:05 <tomayac> ShaneM: I want to re-iterate that we don't do special processing of elements - we should not talk about <meta> at any point in the RDFa Lite document.
15:45:28 <tomayac> ShaneM: there is nothing about doing Element processing in RDFa, the 'a' is for attribute
15:45:41 <tomayac> ivan: this means i have to withdraw both suggestions, then - I'm ok with removing @rel and @content from RDFa Lite.
15:47:25 <gkellogg> q+
15:47:48 <manu1> q+
15:47:50 <manu1> ack gkellogg
15:48:02 <tomayac> ivan: However, you can't put information in meta without using the @content attribute
15:49:26 <tomayac> ivan: If i put myself in a webmaster's shoes, I'll hit the issue of @content eventually
15:49:32 <manu1> q+
15:49:42 <tomayac> ivan: What do i do if there's no mention of @content in the RDFa Lite document
15:50:02 <tomayac> manu1: I understand your point, Ivan
15:50:19 <tomayac> manu: We need to be clear about the use cases that the majority of people will need to support and express how to address them with RDFa Lite
15:50:43 <tomayac> manu1: My point is that I don't think that @content is something that many people will need - and if they /do/ need it - then they can just use it and RDFa Processors will pick it up.
15:50:52 <tomayac> manu1: So, for the OGP examples - if Facebook needed it, they have documented it and their web masters are using it.
15:51:09 <tomayac> ivan: some examples exist in where they use link and meta
15:51:31 <tomayac> gkellogg: regarding content and facebook, i am seeing the concept abused in OGP - people are putting links in @content.
15:51:37 <manu1> ack manu1
15:51:38 <tomayac> ivan: let's not go there now, we all agree that OGP usage isn't as ideal as it could be - but they made those decisions based on what they thought their authors would be comfortable with doing.
15:52:05 <tomayac> manu1: I still believe we leave @content and @rel out until someone says they need it
15:52:27 <tomayac> ivan: we can put it as an open issue in the document, we can add it later, as this is a first public working draft
15:53:10 <manu1> PROPOSAL: Remove references to the @rel attribute from RDFa Lite.
15:53:14 <ShaneM> +1
15:53:14 <manu1> +1
15:53:15 <niklasl> +1
15:53:15 <scor_> +1
15:53:15 <gkellogg> +1
15:53:16 <tomayac> tomayac: +1
15:53:19 <ivan> +1
15:53:34 <manu1> RESOLVED: Remove references to the @rel attribute from RDFa Lite.
15:54:15 <niklasl> q+
15:54:24 <tomayac> manu: I'll add an open issue to the document, then.
15:54:41 <tomayac> niklasl: Should RDFa Lite mention that it's dedicated for authors, and not implementors?
15:54:47 <tomayac> manu: i don't think so
15:55:14 <tomayac> manu1: it just comes across as a simple thing that authors can read. Implementers will know that the document doesn't have enough information in it for an implementation.
15:55:24 <manu1> ack niklasl
15:55:32 <tomayac> manu1: the ones who care about the details, can go to RDFa Core
15:55:32 <manu1> Topic: @rel and @property Symmetry
15:56:24 <tomayac> niklasl: Should @property do chaining if there is a typeof attribute? Why does it do it differently from @rel?
15:56:42 <ivan> is the case Niklas refers to
15:56:50 <tomayac> manu1: I think making @rel and @property do the same thing would create a large backwards incompatibility problem.
15:56:56 <tomayac> ivan: not sure about that
15:57:11 <tomayac> gkellogg: the use case is that if you want to have an anchor
15:57:50 <tomayac> gkellogg: i think using @typeof to really communicate you want to use chaining is a good thing - doesn't break legacy markup.
15:58:11 <tomayac> ivan: an empty typeof might solve this, but that's a bit of a hack.
15:58:20 <tomayac> niklasl: an empty @typeof is kind of strange
15:58:58 <tomayac> ivan: I think this is a question of balancing a very generic use case and being specific
15:59:05 <ivan> <a property="ex:prop" href=""><span property="dc:title">something</span></a>
15:59:53 <niklasl> <a rel="ex:prop" href="" property="dc:title">something</a>
15:59:55 <tomayac> ivan: i would hate to lose that use case
16:00:49 <ivan> <a property="foaf:homepage" href="...">lots of foaf things here</a>
16:01:25 <tomayac> niklasl: i have to problems with that - don't we want the chaining rules to be the same between @rel and @property?
16:01:25 <manu1> q+
16:01:29 <manu1> q-
16:01:36 <manu1> q+ to end the telco
16:02:02 <ShaneM> for example in the RDFa Core 1.1 document we do this:
16:02:02 <ShaneM> <dd rel="bibo:editor"><span typeof="foaf:Person"><a href="" content="Shane McCarron" property="foaf:name" rel="foaf:homepage">Shane McCarron</a>, Applied Testing and Technology, Inc. <a href="" rel="foaf:mbox"></a> </span></dd>
16:02:35 <tomayac> niklasl: @property and @rel are not symmetric
16:02:50 <tomayac> niklasl: when property behaves like rel, it doesn't really behave like rel
16:03:02 <ivan> to Shane: this will actually work like RDFa 1.0, because the apperence of @rel switches the old behaviour
16:03:43 <tomayac> niklasl: I am skeptical about how people will parse links with a lot of statements
16:04:03 <tomayac> manu1: I have a feeling that whenever someone uses more than three attributes on an element with RDFa, it's almost always going to be wrong... which is why we have debuggers. 
16:04:17 <tomayac> ivan: Shane's use case is mostly for the hackers :P
16:04:33 <gkellogg> q+
16:04:55 <tomayac> manu1: This is the basic argument against RDFa... that when you start mixing and matching too many attributes on the same element, it becomes difficult to understand what subject applies to what object - using many attributes in one element causes complexity that you need a debugger to solve. It's a perfectly reasonable argument against RDFa and the response to it should be: If you're not an expert, don't put more than two RDFa attributes on a single element at a time.
16:04:59 <manu1> ack manu1
16:04:59 <Zakim> manu1, you wanted to end the telco
16:05:05 <manu1> ack gkellogg
16:05:25 <tomayac> gkellogg: If we were to do this again, @rel would probably not do implicit chaining
16:05:36 <ShaneM> I agree - we need to be backward compatible for chaining of @rel - that's why we have the processing rules that we do today.
16:05:42 <tomayac> gkellogg: Yes, we need to preserve the behavior for backwards compatibility.
16:05:49 <tomayac> manu1: We're out of time for the call today. I won't be able to make the call next week - I'll be at W3Conf. Ivan may be able to run the call if he's available.
16:11:39 <Zakim> -Ivan
16:11:40 <Zakim> -gkellogg
16:11:40 <Zakim> -manu1
16:11:44 <Zakim> -scor
16:11:50 <Zakim> -niklasl
16:12:21 <manu1> zakim, who is on the call?
16:12:21 <Zakim> On the phone I see ShaneM, tomayac
16:12:30 <manu1> zakim, drop tomayac
16:12:31 <Zakim> tomayac is being disconnected
16:12:31 <Zakim> -tomayac