14:48:36 RRSAgent has joined #rdfa 14:48:36 logging to http://www.w3.org/2011/12/01-rdfa-irc 14:48:38 RRSAgent, make logs world 14:48:38 Zakim has joined #rdfa 14:48:40 Zakim, this will be 7332 14:48:40 ok, trackbot; I see SW_RDFa()10:00AM scheduled to start in 12 minutes 14:48:41 Meeting: RDF Web Applications Working Group Teleconference 14:48:41 Date: 01 December 2011 14:54:36 niklasl has joined #rdfa 14:58:59 scor has joined #rdfa 14:59:44 SW_RDFa()10:00AM has now started 14:59:51 +scor 14:59:58 +??P16 15:00:05 zakim, I am ??P16 15:00:05 +manu1; got it 15:00:50 +??P13 15:00:57 zakim, I am ??P13 15:00:57 +niklasl; got it 15:02:26 +??P21 15:02:39 zakim, I am ??P21 15:02:39 +gkellogg; got it 15:07:12 http://www.w3.org/2007/08/pyRdfa/Validator.html 15:07:39 ShaneM has joined #rdfa 15:07:51 "The validator does not analyze the HTML/XML content itself. It is advised to use, e.g., the separate HTML validator for that purpose." 15:08:06 +??P3 15:08:18 zakim, who is on the phone? 15:08:18 On the phone I see scor, manu1, niklasl, gkellogg, ??P3 15:08:20 zakim, ??P3 is ShaneM 15:08:20 +ShaneM; got it 15:08:35 zakim, who is on the call? 15:08:35 On the phone I see scor, manu1, niklasl, gkellogg, ShaneM 15:10:24 Scribe: scro 15:10:26 Scribe: scor 15:10:57 Agenda: http://lists.w3.org/Archives/Public/public-rdfa-wg/2011Nov/0190.html 15:11:46 Regrets: Steven 15:12:00 TOPIC: Publish RDFa Lite 1.1 as a First Public Working Draft 15:12:13 q+ 15:12:14 Note that there is a publication moratorium in < 2 weeks 15:12:24 ack gkellogg 15:12:31 Can we go ahead and publish RDFa Lite as FPWD? 15:13:02 gkellogg: aren't people going to be confused but the several drafts that the public is linking it to? 15:13:09 s/but/by 15:13:12 q+ about publication process 15:13:30 q+ to talk about publication process 15:13:36 manu1: not in favor of making the 119 change 15:14:00 gkellogg: Ben didn't seem to have any issue with that 15:14:01 ben said: No specific issues come to mind, so if this feels right to the working group, go for it. 15:16:04 Topic: ISSUE-119: Replace @about with @resource in RDFa Lite 15:16:15 http://www.w3.org/2010/02/rdfa/track/issues/119 15:16:32 PROPOSAL: Remove @about in RDFa Lite 1.1 and replace it with @resource. 15:16:36 -1 15:16:37 +1 15:16:38 +1 15:16:40 +1 15:16:49 q+ 15:16:53 +1 15:16:55 ack shanem 15:16:55 ShaneM, you wanted to talk about publication process 15:17:42 manu1: we have a short name approved ready for publication 15:18:15 ack scor 15:20:09 q+ 15:20:24 ack niklasl 15:20:50 manu1: worried about all the RDFa examples and tutorial out there, all use @about extensively 15:21:06 the spec also uses @about all over the place 15:21:30 niklasl: using @resource makes the markup simpler 15:21:39 q+ 15:21:39 manu1: how does it make it simpler? 15:22:06 niklasl: @typeof sticks to @about 15:22:19 q+ 15:22:26 ack gkellogg 15:23:21 q+ to say that @about doesn't have the IRI issue. 15:23:57 gkellogg: potential confusion about the magnetic behavior of @typeof and @about. 15:24:22 ack scor 15:24:23 gkellogg: there is also the HTML IRI issue, @about is sometimes made redundant. 15:25:51 scor: Maybe we should take what we learned about @resource, and instead of replacing @about... maybe we should fix @about and remove the magnetic property of @typeof? Probably too much of a change, break too many implementations. 15:25:56 ack manu1 15:25:57 manu1, you wanted to say that @about doesn't have the IRI issue. 15:26:55 manu1: the IRI issue is on href and src, there is nothing we can do to fix that 15:27:12 using @resource is not going to fix that 15:27:38 gkellogg: another way to do that would be put in some IRI escaping 15:28:03 gkellogg: I think there is an issue against that already with HTML5 15:28:37 q+ 15:29:06 manu1: the way we've been teaching RDFa is that we talk about something, we set the subject with @about 15:29:20 ... so many tutorial out there using @about 15:29:53 ... the magnetic @typeof is actually a nice feature. 15:30:23 ... though it can come in the way sometimes 15:30:49 ... I'm concerned this is going to confuse people who already started to implement RDFa 15:30:55 q+ 15:31:22 ack niklasl 15:33:04 niklasl: I see your point. my feeling is that this form of RDFa 1.1 is more intuitive with @resource 15:33:43 q+ to note that tutorials don't get deprecated, they just stick around and confuse people. 15:33:44 ... of course the tutorial and introductions would become deprecated (they probably include a lot of @rel too) 15:33:58 ack scor 15:34:44 scor: Two things - the old attribute, @instanceof is still present in some tutorials out there - small point. Main point: If people like Gregg or Niklas want to use @resource, they could still use it (except, they wouldn't be able to call their document RDFa 1.1 Lite), right? 15:34:46 q+ to support the position that @about is more meaningful as a name 15:34:49 Niklas: That's true. 15:35:41 scor: Are the people learning RDFa 1.1 going to have the same problems as Niklas and Gregg? I don't know. There may be tutorials that go into @resource... 15:35:49 Niklas: There are tutorials that use @rel today too. 15:36:05 niklasl: I think we need to do some kind of outreach 15:36:15 q+ 15:36:26 ... RDFa is quite nascent in a way, many people don't use it yet 15:36:35 q+ 15:36:37 ack manu1 15:36:37 manu1, you wanted to note that tutorials don't get deprecated, they just stick around and confuse people. 15:38:24 manu1: it concerns me that we keep making more and more changes, without any proof it is going to make RDFa better 15:38:37 Note that replacing @about with @resource in RDFa 1.1 Lite doesn't change RDFa 1.1 Core 15:38:47 ... dangerous position to take because we don't know yet the ramifications of these changes 15:39:35 ... before we got into LC 15:39:37 ack shaneM 15:39:37 ShaneM, you wanted to support the position that @about is more meaningful as a name 15:40:05 ShaneM: the name 'about' has a strong meaning, there is value in that 15:40:17 ... resource is less meaningful and heavily loaded 15:40:42 ShaneM: we're not changing RDFa 1.1 here 15:40:58 manu1: we're talking about changing the best practice of RDFa 15:41:36 ShaneM: it's fine to tell people we've learnt a lesson, and here is a better way of using it 15:41:49 ... the old @about way still works 15:42:25 ack gkellogg 15:42:40 ... from a technical perspective there is nothing that's going to change in the processors 15:43:07 gkellogg: Ivan adds some additional output in his distiller to help best practices... 15:43:12 I actually think that is a BAD Idea. a processor should not point out that you use things that are outside of lite. 15:43:20 gkellogg: we're not talking about changing RDFa 1.1 at all 15:44:08 ... Lite is there to address some specific concerns and create a simpler profile and inline with schema.org snippets 15:45:04 q+ 15:45:09 ack scor 15:45:12 ... would it be reasonable to put an issue note in the Lite document, would be a good way to get feedback 15:45:27 scor: I think my issue was covered by Shane. 15:45:30 ack niklasl 15:45:38 q+ to propose a way forward. 15:45:40 +1 to adding a comment in RDFa 1.1 Lite indicating we might want to recommend @resource as a best practice 15:45:53 niklasl: how about considering adding resource to Lite? 15:46:06 ack manu1 15:46:06 manu1, you wanted to propose a way forward. 15:46:09 q+ 15:47:02 manu1: hesitant to make changes without community input, so we could indeed put in an issue re @resource 15:47:30 ... re niklasl: adding an additional attribute will make people think it's more complicated that it actually is 15:47:47 q+ 15:48:12 ack scor 15:48:18 ... how about we go ahead and publish Lite with an issue and link to the niklasl email 15:49:40 scor: I think I agree with publishing RDFa Lite 1.1 and including an issue.... but this may come across as flip-flopping on the issue. 15:49:49 q+ 15:50:14 ack gkellogg 15:51:14 gkellogg: natural for this group to learn from micro data where it makes sense 15:51:32 ... why is it done that way, why not reusing it? 15:52:48 PROPOSAL: Remove @about in RDFa Lite 1.1 and replace it with @resource. 15:53:02 -0.9 15:53:05 +1 15:53:06 +0 15:53:10 +0.5 15:53:14 q+ 15:53:21 ack scor 15:53:38 +0.1 15:54:50 PROPOSAL: Publish RDFa Lite 1.1 as is. 15:55:04 +0.5 15:55:05 +0.5 15:55:07 +0.5 15:55:13 +0.1 15:55:21 +0 15:55:32 PROPOSAL: Publish RDFa Lite 1.1 with an issue marker specifying that we are considering replacing @about with @resource. 15:55:36 +1 15:55:36 +1 15:55:37 +1 15:55:37 +0.75 15:55:42 +1 15:55:55 RESOLVED: Publish RDFa Lite 1.1 with an issue marker specifying that we are considering replacing @about with @resource. 15:56:05 q+ 15:56:35 +q about a wiki page 15:57:00 Put a small example in the note. also perhaps mention that it would in no way obviate existing uses of @about? 15:57:56 Topic: Publish RDFa Lite 1.1 as a First Public Working Draft 15:58:09 q+ 15:58:35 http://www.w3.org/2010/02/rdfa/drafts/2011/WD-rdfa-lite-20111128/Overview.html 15:59:26 … http://lists.w3.org/Archives/Public/public-rdfa-wg/2011Nov/0119.html 16:00:32 ack niklasl 16:01:15 danbri might have a thought on passing the @about/@resource issue by schema.org members 16:02:53 PROPOSAL: Publish RDFa Lite 1.1 as a First Public Working Draft with the short name 'rdfa-lite' on Thursday, December 8th 2011. 16:02:57 +1 16:02:59 +1 16:02:59 +1 16:03:05 +1 16:03:17 +1 16:03:19 RESOLVED: Publish RDFa Lite 1.1 as a First Public Working Draft with the short name 'rdfa-lite' on Thursday, December 8th 2011. 16:03:31 Topic: Publish RDFa 1.1 Primer as updated Working Draft 16:03:41 http://www.w3.org/2010/02/rdfa/drafts/2011/WD-rdfa-primer-20111128/Overview.html 16:04:31 manu1: Ivan made the magnetic change in the primer, it is up to date 16:04:35 q+ to propose we push a working draft of core too 16:04:40 ... and it uses vocab pretty heavily 16:04:42 ack shaneM 16:04:47 ShaneM, you wanted to propose we push a working draft of core too 16:05:01 ShaneM: how about pushing core 16:05:17 http://www.w3.org/2010/02/rdfa/sources/rdfa-core/Overview-src.html 16:07:14 PROPOSAL: Publish RDFa 1.1 Primer as an updated Working Draft on Thursday, December 8th 2011. 16:07:20 +1 16:07:21 +1 16:07:21 +1 16:07:22 +1 16:07:22 +1 16:07:27 RESOLVED: Publish RDFa 1.1 Primer as an updated Working Draft on Thursday, December 8th 2011. 16:07:40 Topic: Publish RDFa Core 1.1 16:08:15 q+ to ask about status of HTML+RDFa 1.1 16:08:20 http://www.w3.org/2010/02/rdfa/sources/rdfa-core/Overview-src.html 16:08:37 ack gkellogg 16:08:37 gkellogg, you wanted to ask about status of HTML+RDFa 1.1 16:09:28 gkellogg: should the equivalent changes be made to HTML+RDFa 1.1 as well? 16:10:10 manu1: it would be more work since it's in the HTML WG 16:10:14 and it's current in LC 16:10:32 danbri: there should be a wiki up soon 16:10:42 ok 16:11:32 manu1: the HTML+RDFa has typically been lagging behind 16:11:45 just attribute naming? 16:12:04 q? 16:12:09 danbri: see http://www.w3.org/2010/02/rdfa/track/issues/119 and http://lists.w3.org/Archives/Public/public-rdfa-wg/2011Nov/0119.html 16:12:46 wouldn't that break back-compatibility? 16:13:05 danbri: not removing from RDFa 1.1 core, just Lite 16:13:59 danbri: no, it has worked like that since RDFa 1.0 - this is "just" about the practice 16:14:30 s/practice/best practices 16:14:36 can one of you send a summary that i can draw schema.org folks' attention to, then? try to make it self-contained as possible... 16:14:45 I propose we wait on updating the core 16:14:51 niklasl will work on a wiki page with examples 16:14:58 yes 16:15:13 (is this the same thing microdata calls 'itemid' btw?) 16:15:17 scribe: gkellogg 16:15:24 Topic: ISSUE-115: Fragment ID explanation is misleading 16:15:33 http://www.w3.org/2010/02/rdfa/track/issues/115 16:16:02 manu: clarify that @id is different from @about 16:16:11 (.. yes, basically; this would make Lite more isomorphic with microdata AFAIK) 16:16:30 http://www.w3.org/2010/02/rdfa/drafts/2011/WD-rdfa-lite-20111128/Overview.html#about 16:16:46 … They are not the same thing. Instead, we changed language in section 2.2 16:17:28 … not the same as TAG issue with fragids. TAG issue is if @id and @about are in the same "entity space". Does it identify a concept or an element. 16:17:59 … sebastian was talking about a different issue. Reworded to clarify that it's not a "clickable link" 16:18:12 … just an editorial issue. 16:19:04 http://lists.w3.org/Archives/Public/public-rdfa-wg/2011Nov/0025.html 16:19:16 … We implemented his "B" suggestion. 16:19:50 Topic: ISSUE-108: Refine/deprecate Link relations 16:20:15 http://www.w3.org/2010/02/rdfa/track/issues/108 16:20:48 manu: we were going to use IETF link relations list, then we found out HTML5 defers to Microformats community. 16:21:03 … They, in turn, use an open Wiki, which changes all the time. 16:21:32 http://lists.w3.org/Archives/Public/public-rdfa-wg/2011Nov/0170.html 16:21:33 q+ 16:21:35 … We didn't feel that the list of Microformats link relations was stable enough to put in RDFa 1.1 Core spec. 16:22:21 … Ivan, in an email, suggests that we have a different set for XHTML and HTML5. 16:22:32 … In RDFa Core, we should have "described by" 16:23:09 ack niklasl 16:23:13 … RDFa has just the one, XHTML+RDFa has the existing 16:23:16 http://wiki.creativecommons.org/Rdfa#rel.3D.22license.22 16:23:19 Our relations are here: http://www.w3.org/1999/xhtml/vocab/ 16:23:44 rel="license" This is the most basic and fundamental part of CC's usage of RDFa, and is always included in the HTML offered, regardless of whether users fill out the "Additional Information" section. 16:23:44 niklasl: CC uses @rel="license", hoped they would use cc:license 16:24:34 q+ to remind that the role relation is critical 16:24:39 q+ 16:24:39 manu: we need to crawl to see what actual link relations are used on the web. 16:24:42 ack shanem 16:24:42 ShaneM, you wanted to remind that the role relation is critical 16:24:57 shanem: we also have the role spec, which depends on @rel="role" 16:25:03 ack niklasl 16:25:32 niklasl: we discussed using XHV as the default @vocab 16:26:06 … This would allow any use of rel values to generate IRIs against that vocabulary. 16:26:19 … Makes it easier to maintain separately, without requiring processor update. 16:26:23 +1 to just saying XVH is the default vocabulary 16:26:24 q+ to support niklasl's position. 16:26:32 ack manu1 16:26:32 manu1, you wanted to support niklasl's position. 16:27:03 manu: support that position, as it's backwards compatible, but we will start generating more "junk" triples. 16:27:29 q+ 16:28:00 niklasl: we don't talk about fixing stylesheet, for example. 16:28:18 ack gkellogg 16:29:07 gkellogg: Jeni has mentioned a concern - one of the problems with generating triples for link relations is that the semantics for HTML are against the document and not against the current subject. A separate spec like GRDDL might generate triples based on rel relations with the subject being about the document. 16:29:20 q+ to consider default vocal a "black list" 16:29:21 gkellogg: They could co-exist, but you may get two different sets of triples out. 16:29:24 ack niklasl 16:29:24 niklasl, you wanted to consider default vocal a "black list" 16:29:27 … this does allow something to be inferred if there are two triples. 16:29:57 niklasl: We could consider having a "black list", and exclude some rel values from generating triples. 16:30:34 manu: we're in a territory where we'll have to examine on a case-by-case basis. 16:30:49 … differences between HTML and CC on rel="license" 16:30:58 … no easy solutions. 16:31:07 q+ 16:31:12 ack niklasl 16:31:14 … multiple ways to interpret 16:31:50 niklasl: if you use @about, or some other chaining operation, it seems clear what the author's intent is. 16:32:43 q+ to clarify aboiuyt head 16:32:48 … proposal remains to define the default @vocab as XHV. Place these things in , and unless there's an @about, it has the same meaning as HTML. 16:32:57 ack shanem 16:32:57 ShaneM, you wanted to clarify aboiuyt head 16:33:26 shanem: If I have @rel="stylesheet" in , there's an implicit @about="". 16:34:56 niklasl: implicit @about in has no meaning, unless you also us an @typeof. Adding @about="" doesn't change anything. 16:35:20 manu: that would make @rel always generate a triples. If there is no term mapping, it is always attached to the XHV namespace. 16:35:46 q+ 16:35:54 shanem: This group does have access to change XHV document. 16:36:02 … HTML WG does too. 16:36:04 ack niklasl 16:36:34 niklasl: this also raises the necessity to define describedby in XHV, making it the same as the POWDER URI. 16:37:05 … needs owl:sameAs, also need to put in default profiles. 16:37:39 manu: terms still have use in the default profile. 16:37:46 q+ 16:37:50 xhv:describedby owl:sameAs powder:describedby 16:38:17 niklasl: if we only use default profile, this would be useful. 16:38:31 … I'd like to see it in the XHV vocab. 16:38:32 ack gkellogg 16:38:58 shanem: we can define terms, in spite of @vocab. 16:39:41 … placing them in XHV is a _fine_ thing to do. For "describedby" in particular, I'd make a term in the default profile. 16:39:43 ack gkellogg 16:40:11 gkellogg: If we do make XHV the default vocabulary, we need to emit a vocab triple for it, or we need to add some other rules in the expansion text. 16:40:34 gkellogg: We need to consider what happens when we make XHV the default vocabulary on expansion. 16:40:58 shanem: XVH doc uniquely unsuitable for "follow your nose" 16:41:12 Current definition from XHV chapter: 16:41:12
chapter
chapter refers to a resource serving as a chapter in a collection.
16:41:58 manu: always generate triples for @rel, either as term definition, or XHV. 16:44:07 term ::= NCNameStartChar termChar* 16:44:12 termChar ::= ( NameChar - ':' ) | '/' 16:44:54 shanem: @rel="food:name", and "food" isn't defined, it would be ignored. 16:45:43 16:45:46 … never mind. 16:45:49 @rel="urn:example:stuff" 16:46:10 16:46:16 … TERM isn't an NC name, it's NCName + '/'.. 16:47:17 .. we were also explicit about excluding ":" in term, which saves us here :) 16:47:19 manu: it's true for every use, not just @rel?!? 16:47:52 … @property, @rel will always generate a triple. 16:48:18 … @typeof will always have a type. Also @rev. 16:48:26 q+ 16:48:58 ack gkellogg 16:50:04 gkellogg: I think we want to have XHV as the default vocabulary. I'm concerned about being so permissive in generating triples. The safest thing to do for HTML5 is to not generate anything - it makes us more compatible with other GRDDL-like processing. 16:50:32 gkellogg: I think we should use describedby in RDFa Profile... maybe a small set of terms defined for HTML5... but not the full link relation set we've used to date. 16:51:11 manu: two proposals, 1) make XHV default, 2) no default, just terms defined in default profile. 16:51:37 PROPOSAL: Make the XHTML Vocabulary the default vocabulary for RDFa Core 1.1. 16:51:40 -1 16:51:44 -1 16:51:50 +1 16:51:58 +0 16:52:32 +0 16:52:38 I am opposed to having XHTML and HTML5 with different interprations of core concepts such as license 16:55:28 Core default initial context contains terms such as describedby, license, role... 16:55:35 manu: should we have two default profile docs, one for Core, and another for "HTML" languages, with legacy XHV link relations. 16:56:01 shanem: clarification, if there's a term defined, I can't override that, true? 16:56:52 manu: this argues that we should be careful as what we define as default terms in the profile. 16:57:11 … this could clash with schema.org, for example, attributes if @vocab is used. 16:58:09 do any terms clash currently? 16:58:19 manu: three profiles, RDF Core (described by, license, role), one for HTML+RDFa, which is empty, plus another for XHTML+RDFa, which is backwards compatible. 16:59:21 PROPOSAL: RDFa 1.1 will have 3 default profiles, RDFa Core 1.1 will contain the terms 'describedby', 'license', and 'role', HTML+RDFa will not have any terms, XHTML+RDFa will have all terms required for backwards compatability. 16:59:45 +1 16:59:53 +1 17:00:00 +1 17:00:05 +0 17:00:10 (clarification: XHTML+RDFa means XHTML1+RDFa) 17:00:14 Current XHV doc: http://www.w3.org/1999/xhtml/vocab/ 17:00:16 A CURIE is comprised of two components, a prefix and a reference. The prefix is separated from the reference by a colon (:). In general use it is possible to omit the prefix, and so create a CURIE that makes use of the 'default prefix' mapping; in RDFa the 'default prefix' mapping is http://www.w3.org/1999/xhtml/vocab#. It's also possible to omit both the prefix and the colon, and so create a CURIE that contains just a reference which makes use of the 'no p 17:00:53 rel=":license" 17:01:07 shanem: this always refers to XHV. 17:01:20 q+ 17:01:36 … Role spec might care about this too. Should encourage to use ":foo" to be unambiguous. 17:01:52 manu: might be confusing for role spec authors. 17:02:08 ack niklasl 17:02:45 niklasl: I'm a bit wary about predefined terms, because of their precedence, which could interfere with @vocab. 17:02:50 The Role Attribute module specification says "The datatype used for @role permits the use of a TERM, a CURIE, or a full URI. RDFa defines a TERM as an item from a vocabulary, and defines how a vocabulary is constructed. The default vocabulary for use with@role is defined in [XHTML-VOCAB]. A host language may define a different default vocabulary." 17:03:05 RESOLVED: RDFa 1.1 will have 3 default profiles, RDFa Core 1.1 will contain the terms 'describedby', 'license', and 'role', HTML+RDFa will not have any terms, XHTML+RDFa will have all terms required for backwards compatability. 17:03:32 -scor 17:04:05 -ShaneM 17:04:07 -manu1 17:04:15 -gkellogg 17:04:21 -niklasl 17:04:23 SW_RDFa()10:00AM has ended 17:04:25 Attendees were scor, manu1, niklasl, gkellogg, ShaneM 17:19:14 ShaneM has left #rdfa 17:21:36 niklasl has left #rdfa 18:59:09 trackbot has joined #rdfa 19:29:01 Zakim has left #rdfa