Chatlog 2011-12-01

From RDFa Working Group Wiki
Revision as of 17:48, 1 December 2011 by Msporny (Talk | contribs)

(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search

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

14:48:36 <RRSAgent> RRSAgent has joined #rdfa
14:48:36 <RRSAgent> logging to http://www.w3.org/2011/12/01-rdfa-irc
14:48:38 <trackbot> RRSAgent, make logs world
14:48:38 <Zakim> Zakim has joined #rdfa
14:48:40 <trackbot> Zakim, this will be 7332
14:48:40 <Zakim> ok, trackbot; I see SW_RDFa()10:00AM scheduled to start in 12 minutes
14:48:41 <trackbot> Meeting: RDF Web Applications Working Group Teleconference
14:48:41 <trackbot> Date: 01 December 2011
14:48:43 <manu1> Guest: Niklas (niklasl) Lindström
14:48:43 <manu1> Guest: Dan (danbri) Brickley
14:54:36 <niklasl> niklasl has joined #rdfa
14:58:59 <scor> scor has joined #rdfa
14:59:44 <Zakim> SW_RDFa()10:00AM has now started
14:59:51 <Zakim> +scor
14:59:58 <Zakim> +??P16
15:00:05 <manu1> zakim, I am ??P16
15:00:05 <Zakim> +manu1; got it
15:00:50 <Zakim> +??P13
15:00:57 <niklasl> zakim, I am ??P13
15:00:57 <Zakim> +niklasl; got it
15:02:26 <Zakim> +??P21
15:02:39 <gkellogg> zakim, I am ??P21
15:02:39 <Zakim> +gkellogg; got it
15:07:39 <ShaneM> ShaneM has joined #rdfa
15:08:06 <Zakim> +??P3
15:08:18 <scor> zakim, who is on the phone?
15:08:18 <Zakim> On the phone I see scor, manu1, niklasl, gkellogg, ??P3
15:08:20 <ShaneM> zakim, ??P3 is ShaneM
15:08:20 <Zakim> +ShaneM; got it
15:08:35 <manu1> zakim, who is on the call?
15:08:35 <Zakim> On the phone I see scor, manu1, niklasl, gkellogg, ShaneM
15:10:26 <manu1> Scribe: scor
15:10:57 <manu1> Agenda: http://lists.w3.org/Archives/Public/public-rdfa-wg/2011Nov/0190.html
15:11:46 <ShaneM> Regrets: Steven
15:12:00 <scor> TOPIC: Publication of RDFa 1.1 documents
15:12:13 <gkellogg> q+
15:12:14 <ShaneM> Note that there is a publication moratorium in < 2 weeks
15:12:24 <manu1> ack gkellogg
15:12:31 <scor> Can we go ahead and publish RDFa Lite as FPWD?
15:13:02 <scor> gkellogg: Shouldn't we discuss ISSUE-119 first? Replacing @about with @resource? Aren't people going to be confused by the several drafts if we publish and then make that change?
15:13:12 <ShaneM> q+ about publication process
15:13:30 <ShaneM> q+ to talk about publication process
15:13:36 <scor> manu1: I'm really against making the ISSUE-119 change - we already have agreement from schema.org folks for RDFa Lite, tutorials use @about heavily, all of the examples across all of the documents would have to change, it would create confusion on when to use @resource and when to use @about, it's a fairly big best practices change very late in the process, etc.
15:14:00 <scor> gkellogg: Ben didn't seem to have any issue with that
15:14:01 <ShaneM> ben said: No specific issues come to mind, so if this feels right to the working  group, go for it. 
15:16:04 <manu1> Topic: ISSUE-119: Replace @about with @resource in RDFa Lite
15:16:15 <manu1> http://www.w3.org/2010/02/rdfa/track/issues/119
15:16:32 <scor> manu1: Let's start with a straw poll to see how the group feels about ISSUE-119.
15:16:32 <manu1> PROPOSAL: Remove @about in RDFa Lite 1.1 and replace it with @resource.
15:16:36 <manu1> -1
15:16:37 <niklasl> +1
15:16:38 <gkellogg> +1
15:16:40 <scor> scor: +1
15:16:49 <scor> q+
15:16:53 <ShaneM> +1
15:16:55 <manu1> ack shanem
15:16:55 <Zakim> ShaneM, you wanted to talk about publication process
15:17:42 <scor> Shanem: Can we publish in time, do we even have a short name approved?
15:17:42 <scor> manu1: we have a short name approved ready for publication
15:18:15 <manu1> ack scor
15:20:09 <niklasl> q+
15:20:24 <manu1> ack niklasl
15:20:50 <scor> manu1: worried about all the RDFa examples and tutorial out there, all use @about extensively
15:21:06 <scor> the spec also uses @about all over the place
15:21:30 <scor> niklasl: using @resource makes the markup simpler
15:21:39 <gkellogg> q+
15:21:39 <scor> manu1: how does it make it simpler?
15:22:06 <scor> niklasl: @typeof sticks to @about
15:22:19 <scor> q+
15:22:26 <manu1> ack gkellogg
15:23:21 <manu1> q+ to say that @about doesn't have the IRI issue.
15:23:57 <scor> gkellogg: potential confusion about the magnetic behavior of @typeof and @about. 
15:24:22 <manu1> ack scor
15:24:23 <scor> gkellogg: there is also the HTML IRI issue, @about is sometimes made redundant.
15:25:51 <manu1> 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 <manu1> ack manu1
15:25:57 <Zakim> manu1, you wanted to say that @about doesn't have the IRI issue.
15:26:55 <scor> manu1: the IRI issue is on href and src, there is nothing we can do to fix that
15:27:12 <scor> using @resource is not going to fix that
15:27:38 <scor> gkellogg: another way to do that would be put in some IRI escaping
15:28:03 <scor> gkellogg: I think there is an issue against that already with HTML5
15:28:37 <niklasl> q+
15:29:06 <scor> manu1: the way we've been teaching RDFa is that we talk about something, we set the subject with @about
15:29:20 <scor> ... so many tutorial out there using @about
15:29:53 <scor> ... the magnetic @typeof is actually a nice feature.
15:30:23 <scor> ... though it can come in the way sometimes
15:30:49 <scor> ... I'm concerned this is going to confuse people who already started to implement RDFa
15:30:55 <scor> q+
15:31:22 <manu1> ack niklasl
15:33:04 <scor> niklasl: I see your point. my feeling is that this form of RDFa 1.1 is more intuitive with @resource
15:33:43 <manu1> q+ to note that tutorials don't get deprecated, they just stick around and confuse people.
15:33:44 <scor> ... of course the tutorial and introductions would become deprecated (they probably include a lot of @rel too)
15:33:58 <manu1> ack scor
15:34:44 <manu1> 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 <ShaneM> q+ to support the position that @about is more meaningful as a name
15:34:49 <manu1> Niklas: That's true.
15:35:41 <manu1> 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 <manu1> Niklas: There are tutorials that use @rel today too.
15:36:05 <scor> niklasl: I think we need to do some kind of outreach
15:36:15 <gkellogg> q+
15:36:26 <scor> ... RDFa is quite nascent in a way, many people don't use it yet
15:36:35 <scor> q+
15:36:37 <manu1> ack manu1
15:36:37 <Zakim> manu1, you wanted to note that tutorials don't get deprecated, they just stick around and confuse people.
15:38:24 <scor> 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 <gkellogg> Note that replacing @about with @resource in RDFa 1.1 Lite doesn't change RDFa 1.1 Core
15:38:47 <scor> ... dangerous position to take because we don't know yet the ramifications of these changes
15:39:35 <scor> ... before we got into LC
15:39:37 <manu1> ack shaneM
15:39:37 <Zakim> ShaneM, you wanted to support the position that @about is more meaningful as a name
15:40:05 <scor> ShaneM: the name 'about' has a strong meaning, there is value in that
15:40:17 <scor> ... resource is less meaningful and heavily loaded
15:40:42 <scor> ShaneM: we're not changing RDFa 1.1 here
15:40:58 <scor> manu1: we're talking about changing the best practice of RDFa 
15:41:36 <scor> ShaneM: it's fine to tell people we've learnt a lesson, and here is a better way of using it
15:41:49 <scor> ... the old @about way still works
15:42:25 <manu1> ack gkellogg
15:42:40 <scor> ... from a technical perspective there is nothing that's going to change in the processors
15:43:07 <scor> gkellogg: Ivan adds some additional output in his distiller to help best practices...
15:43:12 <ShaneM> 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 <scor> gkellogg: we're not talking about changing RDFa 1.1 at all
15:44:08 <scor> ... Lite is there to address some specific concerns and create a simpler profile and inline with schema.org snippets
15:45:04 <niklasl> q+
15:45:09 <manu1> ack scor
15:45:12 <scor> ... would it be reasonable to put an issue note in the Lite document, would be a good way to get feedback
15:45:27 <manu1> scor: I think my issue was covered by Shane.
15:45:30 <manu1> ack niklasl
15:45:38 <manu1> q+ to propose a way forward.
15:45:40 <ShaneM> +1 to adding a comment in RDFa 1.1 Lite indicating we might want to recommend @resource as a best practice
15:45:53 <scor> niklasl: how about considering adding resource to Lite?
15:46:06 <manu1> ack manu1
15:46:06 <Zakim> manu1, you wanted to propose a way forward.
15:46:09 <scor> q+
15:47:02 <scor> manu1: hesitant to make changes without community input, so we could indeed put in an issue re @resource
15:47:30 <scor> ... re niklasl: adding an additional attribute will make people think it's more complicated that it actually is
15:47:47 <scor> q+
15:48:12 <manu1> ack scor
15:48:18 <scor> ... how about we go ahead and publish Lite with an issue and link to the niklasl email
15:49:40 <manu1> 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 <gkellogg> q+
15:50:14 <manu1> ack gkellogg
15:51:14 <scor> gkellogg: natural for this group to learn from micro data where it makes sense
15:51:32 <scor> ... why is it done that way, why not reusing it?
15:52:48 <manu1> PROPOSAL: Remove @about in RDFa Lite 1.1 and replace it with @resource.
15:53:02 <manu1> -0.9
15:53:05 <niklasl> +1
15:53:06 <scor> scor: +0
15:53:10 <gkellogg> +0.5
15:53:14 <scor> q+
15:53:21 <manu1> ack scor
15:53:38 <ShaneM> +0.1
15:54:50 <manu1> PROPOSAL: Publish RDFa Lite 1.1 as is.
15:55:04 <gkellogg> +0.5
15:55:05 <manu1> +0.5
15:55:07 <niklasl> +0.5
15:55:13 <scor> scor: +0.1
15:55:21 <ShaneM> +0
15:55:32 <manu1> PROPOSAL: Publish RDFa Lite 1.1 with an issue marker specifying that we are considering replacing @about with @resource.
15:55:36 <manu1> +1
15:55:36 <scor> scor: +1
15:55:37 <gkellogg> +1
15:55:37 <niklasl> +0.75
15:55:42 <ShaneM> +1
15:55:55 <manu1> RESOLVED: Publish RDFa Lite 1.1 with an issue marker specifying that we are considering replacing @about with @resource.
15:56:05 <niklasl> q+
15:56:35 <scor> +q about a wiki page
15:57:00 <ShaneM> Put a small example in the note.  also perhaps mention that it would in no way obviate existing uses of @about?
15:57:56 <manu1> Topic: Publish RDFa Lite 1.1 as a First Public Working Draft
15:58:09 <niklasl> q+
15:58:35 <manu1> http://www.w3.org/2010/02/rdfa/drafts/2011/WD-rdfa-lite-20111128/Overview.html
15:59:26 <niklasl> … http://lists.w3.org/Archives/Public/public-rdfa-wg/2011Nov/0119.html
16:00:32 <manu1> ack niklasl
16:01:15 <gkellogg> danbri might have a thought on passing the @about/@resource issue by schema.org members
16:02:53 <manu1> 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 <gkellogg> +1
16:02:59 <manu1> +1
16:02:59 <niklasl> +1
16:03:05 <ShaneM> +1
16:03:17 <scor> scor: +1
16:03:19 <manu1> 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 <manu1> Topic: Publish RDFa 1.1 Primer as updated Working Draft
16:03:41 <manu1> http://www.w3.org/2010/02/rdfa/drafts/2011/WD-rdfa-primer-20111128/Overview.html
16:04:31 <scor> manu1: Ivan made the magnetic change in the primer, it is up to date
16:04:35 <ShaneM> q+ to propose we push a working draft of core too
16:04:40 <scor> ... and it uses vocab pretty heavily
16:04:42 <manu1> ack shaneM
16:04:47 <Zakim> ShaneM, you wanted to propose we push a working draft of core too
16:05:01 <scor> ShaneM: how about pushing core
16:05:17 <ShaneM> http://www.w3.org/2010/02/rdfa/sources/rdfa-core/Overview-src.html
16:07:14 <manu1> PROPOSAL: Publish RDFa 1.1 Primer as an updated Working Draft on Thursday, December 8th 2011.
16:07:20 <ShaneM> +1
16:07:21 <niklasl> +1
16:07:21 <scor> scor: +1
16:07:22 <manu1> +1
16:07:22 <gkellogg> +1
16:07:27 <manu1> RESOLVED: Publish RDFa 1.1 Primer as an updated Working Draft on Thursday, December 8th 2011.
16:07:40 <manu1> Topic: Publish RDFa Core 1.1
16:08:15 <gkellogg> q+ to ask about status of HTML+RDFa 1.1
16:08:20 <manu1> http://www.w3.org/2010/02/rdfa/sources/rdfa-core/Overview-src.html
16:08:37 <manu1> ack gkellogg
16:08:37 <Zakim> gkellogg, you wanted to ask about status of HTML+RDFa 1.1
16:09:28 <scor> gkellogg: should the equivalent changes be made to HTML+RDFa 1.1 as well?
16:10:10 <scor> manu1: it would be more work since it's in the HTML WG
16:10:14 <scor> and it's current in LC
16:10:32 <scor> danbri, there should be a wiki up soon 
16:10:42 <danbri> ok
16:11:32 <scor> manu1: the HTML+RDFa has typically been lagging behind
16:11:45 <danbri> just attribute naming?
16:12:04 <manu1> q?
16:12:09 <niklasl> 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 <danbri> wouldn't that break back-compatibility?
16:13:05 <gkellogg> danbri, not removing from RDFa 1.1 core, just Lite
16:13:59 <niklasl> danbri, no, it has worked like that since RDFa 1.0 - this is "just" about the practice
16:14:30 <scor> s/practice/best practices
16:14:36 <danbri> 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 <ShaneM> I propose we wait on updating the core
16:14:51 <scor> niklasl will work on a wiki page with examples
16:14:58 <niklasl> yes
16:15:13 <danbri> (is this the same thing microdata calls 'itemid' btw?)
16:15:17 <gkellogg> scribe: gkellogg
16:15:24 <manu1> Topic: ISSUE-115: Fragment ID explanation is misleading
16:15:33 <manu1> http://www.w3.org/2010/02/rdfa/track/issues/115
16:16:02 <gkellogg> manu: clarify that @id is different from @about
16:16:11 <niklasl> (.. yes, basically; this would make Lite more isomorphic with microdata AFAIK)
16:16:30 <manu1> http://www.w3.org/2010/02/rdfa/drafts/2011/WD-rdfa-lite-20111128/Overview.html#about
16:16:46 <gkellogg> … They are not the same thing. Instead, we changed language in section 2.2
16:17:28 <gkellogg> … 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 <gkellogg> … sebastian was talking about a different issue. Reworded to clarify that it's not a "clickable link"
16:18:12 <gkellogg> … just an editorial issue.
16:19:04 <manu1> http://lists.w3.org/Archives/Public/public-rdfa-wg/2011Nov/0025.html
16:19:16 <gkellogg> … We implemented his "B" suggestion, so his issue has been addressed.
16:19:50 <manu1> Topic: ISSUE-108: Refine/deprecate Link relations
16:20:15 <manu1> http://www.w3.org/2010/02/rdfa/track/issues/108
16:20:48 <gkellogg> manu: we were going to use IETF link relations list, then we found out HTML5 defers to Microformats community.
16:21:03 <gkellogg> … They, in turn, use an open Wiki, which changes all the time.
16:21:32 <manu1> http://lists.w3.org/Archives/Public/public-rdfa-wg/2011Nov/0170.html
16:21:33 <niklasl> q+
16:21:35 <gkellogg> … 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 <gkellogg> … Ivan, in an email, suggests that we have a different set for XHTML and HTML5.
16:22:32 <gkellogg> … In RDFa Core, we should have "described by"
16:23:09 <manu1> ack niklasl
16:23:13 <gkellogg> … RDFa has just the one, XHTML+RDFa has the existing
16:23:16 <niklasl> http://wiki.creativecommons.org/Rdfa#rel.3D.22license.22
16:23:19 <ShaneM> Our relations are here: http://www.w3.org/1999/xhtml/vocab/
16:23:44 <niklasl> 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 <gkellogg> niklasl: CC uses @rel="license", hoped they would use cc:license
16:24:34 <ShaneM> q+ to remind that the role relation is critical 
16:24:39 <niklasl> q+
16:24:39 <gkellogg> manu: we need to crawl to see what actual link relations are used on the web.
16:24:42 <manu1> ack shanem
16:24:42 <Zakim> ShaneM, you wanted to remind that the role relation is critical
16:24:57 <gkellogg> shanem: we also have the role spec, which depends on @rel="role"
16:25:03 <manu1> ack niklasl
16:25:32 <gkellogg> niklasl: we discussed using XHV as the default @vocab
16:26:06 <gkellogg> … This would allow any use of rel values to generate IRIs against that vocabulary.
16:26:19 <gkellogg> … Makes it easier to maintain separately, without requiring processor update.
16:26:23 <ShaneM> +1 to just saying XVH is the default vocabulary
16:26:24 <manu1> q+ to support niklasl's position.
16:26:32 <manu1> ack manu1
16:26:32 <Zakim> manu1, you wanted to support niklasl's position.
16:27:03 <gkellogg> manu: support that position, as it's backwards compatible, but we will start generating more "junk" triples.
16:27:29 <gkellogg> q+
16:28:00 <gkellogg> niklasl: we don't talk about fixing stylesheet, for example.
16:28:18 <manu1> ack gkellogg
16:29:07 <manu1> 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 <niklasl> q+ to consider default vocal a "black list"
16:29:21 <manu1> gkellogg: They could co-exist, but you may get two different sets of triples out.
16:29:24 <manu1> ack niklasl
16:29:24 <Zakim> niklasl, you wanted to consider default vocal a "black list"
16:29:27 <gkellogg> … this does allow something to be inferred if there are two triples.
16:29:57 <gkellogg> niklasl: We could consider having a "black list", and exclude some rel values from generating triples.
16:30:34 <gkellogg> manu: we're in a territory where we'll have to examine on a case-by-case basis.
16:30:49 <gkellogg> … differences between HTML and CC on rel="license"
16:30:58 <gkellogg> … no easy solutions.
16:31:07 <niklasl> q+
16:31:12 <manu1> ack niklasl
16:31:14 <gkellogg> … multiple ways to interpret
16:31:50 <gkellogg> niklasl: if you use @about, or some other chaining operation, it seems clear what the author's intent is.
16:32:43 <ShaneM> q+ to clarify aboiuyt head
16:32:48 <gkellogg> … proposal remains to define the default @vocab as XHV. Place these things in <head>, and unless there's an @about, it has the same meaning as HTML.
16:32:57 <manu1> ack shanem
16:32:57 <Zakim> ShaneM, you wanted to clarify aboiuyt head
16:33:26 <gkellogg> shanem: If I have @rel="stylesheet" in <head>, there's an implicit @about="".
16:34:56 <gkellogg> niklasl: implicit @about in <head> has no meaning, unless you also us an @typeof. Adding @about="" doesn't change anything.
16:35:20 <gkellogg> 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 <niklasl> q+
16:35:54 <gkellogg> shanem: This group does have access to change XHV document.
16:36:02 <gkellogg> … HTML WG does too.
16:36:04 <manu1> ack niklasl
16:36:34 <gkellogg> niklasl: this also raises the necessity to define describedby in XHV, making it the same as the POWDER URI.
16:37:05 <gkellogg> … needs owl:sameAs, also need to put in default profiles.
16:37:39 <gkellogg> manu: terms still have use in the default profile.
16:37:46 <gkellogg> q+
16:37:50 <niklasl> We may want to put this in the XHTML Vocab document - xhv:describedby owl:sameAs powder:describedby 
16:38:17 <gkellogg> niklasl: if we only use default profile, this would be useful.
16:38:31 <gkellogg> … I'd like to see it in the XHV vocab.
16:38:32 <manu1> ack gkellogg
16:38:58 <gkellogg> shanem: we can define terms, in spite of @vocab.
16:39:41 <gkellogg> … 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 <manu1> ack gkellogg
16:40:11 <manu1> 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 <manu1> gkellogg: We need to consider what happens when we make XHV the default vocabulary on expansion.
16:40:58 <gkellogg> shanem: XVH doc uniquely unsuitable for "follow your nose"
16:41:12 <ShaneM> Current definition from XHV chapter:
16:41:12 <ShaneM>   <dt id="chapter" about="#chapter" property='rdfa:term' lang='' xml:lang='' typeof="rdf:Property">chapter</dt>    <dd about="#chapter" property="rdfs:comment"      datatype="xsd:string"><span property='rdfa:uri' lang='' xml:lang='' content='http://www.w3.org/1999/xhtml/vocab#chapter'>chapter</span> refers to a resource serving      as a chapter in a collection. </dd>
16:41:58 <gkellogg> manu: always generate triples for @rel, either as term definition, or XHV.
16:44:07 <niklasl> term     ::=  NCNameStartChar termChar*
16:44:12 <niklasl> termChar ::=  ( NameChar - ':' ) | '/'
16:44:54 <gkellogg> shanem: @rel="food:name", and "food" isn't defined, it would be ignored.
16:45:43 <ShaneM>     <xs:simpleType name='AbsIRI'>         <xs:restriction base='xs:string'>             <xs:pattern value="[\i-[:]][\c-[:]]+:.+" />         </xs:restriction>     </xs:simpleType>
16:45:46 <gkellogg> … never mind.
16:45:49 <niklasl> @rel="urn:example:stuff"
16:46:10 <ShaneM>     <xs:simpleType name="TERM">       <xs:restriction base="xs:Name">         <xs:pattern value="[\i-[:]][/\c-[:]]*" />       </xs:restriction>     </xs:simpleType>
16:46:16 <gkellogg> … TERM isn't an NC name, it's NCName + '/'..
16:47:17 <niklasl> .. we were also explicit about excluding ":" in term, which saves us here :)
16:47:19 <gkellogg> manu: it's true for every use, not just @rel?!?
16:47:52 <gkellogg> … @property, @rel will always generate a triple.
16:48:18 <gkellogg> … @typeof will always have a type. Also @rev.
16:48:26 <gkellogg> q+
16:48:58 <manu1> ack gkellogg
16:50:04 <manu1> 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 <manu1> 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 <gkellogg> manu: two proposals, 1) make XHV default, 2) no default, just terms defined in default profile.
16:51:37 <manu1> PROPOSAL: Make the XHTML Vocabulary the default vocabulary for RDFa Core 1.1.
16:51:40 <manu1> -1
16:51:44 <gkellogg> gkellogg: -1
16:51:50 <niklasl> +1
16:51:58 <ShaneM> +0
16:52:32 <scor> +0
16:52:38 <ShaneM> I am opposed to having XHTML and HTML5 with different interprations of core concepts such as license
16:55:28 <ShaneM> Core default initial context contains terms such as describedby, license, role...  
16:55:35 <gkellogg> manu: should we have two default profile docs, one for Core, and another for "HTML" languages, with legacy XHV link relations.
16:56:01 <gkellogg> shanem: clarification, if there's a term defined, I can't override that, true?
16:56:52 <gkellogg> manu: this argues that we should be careful as what we define as default terms in the profile.
16:57:11 <gkellogg> … this could clash with schema.org, for example, attributes if @vocab is used.
16:58:09 <danbri> do any terms clash currently?
16:58:19 <gkellogg> 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 <manu1> 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 <gkellogg> gkellogg: +1
16:59:53 <manu1> +1
17:00:00 <ShaneM> +1
17:00:05 <niklasl> +0
17:00:10 <manu1> (clarification: XHTML+RDFa means XHTML1+RDFa)
17:00:14 <gkellogg> Current XHV doc: http://www.w3.org/1999/xhtml/vocab/
17:00:16 <ShaneM> 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 <ShaneM> rel=":license"
17:01:07 <gkellogg> shanem: this always refers to XHV.
17:01:20 <niklasl> q+
17:01:36 <gkellogg> … Role spec might care about this too. Should encourage to use ":foo" to be unambiguous.
17:01:52 <gkellogg> manu: might be confusing for role spec authors.
17:02:08 <manu1> ack niklasl
17:02:45 <gkellogg> niklasl: I'm a bit wary about predefined terms, because of their precedence, which could interfere with @vocab.
17:02:50 <ShaneM> 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 <manu1> 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 <Zakim> -scor
17:04:05 <Zakim> -ShaneM
17:04:07 <Zakim> -manu1
17:04:15 <Zakim> -gkellogg
17:04:21 <Zakim> -niklasl
17:04:23 <Zakim> SW_RDFa()10:00AM has ended
17:04:25 <Zakim> Attendees were scor, manu1, niklasl, gkellogg, ShaneM
# SPECIAL MARKER FOR CHATSYNC.  DO NOT EDIT THIS LINE OR BELOW.  SRCLINESUSED=00000361