Chatlog 2011-08-11

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

13:41:52 <RRSAgent> RRSAgent has joined #rdfa
13:41:52 <RRSAgent> logging to http://www.w3.org/2011/08/11-rdfa-irc
13:41:54 <trackbot> RRSAgent, make logs world
13:41:54 <Zakim> Zakim has joined #rdfa
13:41:56 <trackbot> Zakim, this will be 7332
13:41:56 <Zakim> ok, trackbot; I see SW_RDFa()10:00AM scheduled to start in 19 minutes
13:41:57 <trackbot> Meeting: RDF Web Applications Working Group Teleconference
13:41:57 <trackbot> Date: 11 August 2011
13:51:37 <manu> Chair: Manu
13:52:06 <manu> Guest: Stéphane (scor) Corlosquet
13:52:06 <manu> Guest: Henri (bergie) Bergius
13:52:06 <manu> Guest: Niklas (lindstream) Lindström
13:52:06 <manu> Guest: Toby (tinkster) Inkster
13:57:50 <manu> Agenda: http://lists.w3.org/Archives/Public/pu
13:52:27 <manu> Agenda: http://lists.w3.org/Archives/Public/public-rdfa-wg/2011Aug/0019.html
13:55:03 <Zakim> SW_RDFa()10:00AM has now started
13:55:10 <Zakim> +??P5
13:55:25 <gkellogg> zakim, ??P5 is me
13:55:25 <Zakim> +gkellogg; got it
13:55:39 <manu> scribenick: gkellogg
13:55:42 <manu> Scribe: Gregg
13:56:15 <Zakim> +??P6
13:57:00 <manu> zakim, I am ??P6
13:57:00 <Zakim> +manu; got it
13:57:04 <scor> scor has joined #rdfa
13:57:11 <Zakim> + +68185775aaaa
13:57:27 <SebastianGermesin> Zakim, I am aaaa
13:57:27 <Zakim> +SebastianGermesin; got it
13:57:33 <ivan> zakim, dial ivan-voip
13:57:33 <Zakim> ok, ivan; the call is being made
13:57:34 <Zakim> +Ivan
13:59:23 <Zakim> + +1.781.866.aabb
13:59:47 <Zakim> +??P12
14:00:05 <MacTed> MacTed has joined #rdfa
14:00:12 <niklasl> zakim, I am ??P12
14:00:12 <Zakim> +niklasl; got it
14:00:27 <tomayac> tomayac has joined #rdfa
14:00:58 <manu> zakim, who is on the call?
14:00:58 <Zakim> On the phone I see gkellogg, manu, SebastianGermesin, Ivan, +1.781.866.aabb, niklasl
14:01:22 <manu> zakim, aabb is scor
14:01:23 <Zakim> +scor; got it
14:03:43 <ivan> zakim, who is here?
14:03:43 <Zakim> On the phone I see gkellogg, manu, SebastianGermesin, Ivan, scor, niklasl
14:03:46 <Zakim> On IRC I see tomayac, MacTed, scor, Zakim, RRSAgent, tinkster, bergie, niklasl, ivan, manu1, trackbot, SebastianGermesin, gkellogg, manu
14:03:48 <Zakim> +Aharon
14:03:51 <Zakim> +??P24
14:04:01 <ShaneM> ShaneM has joined #rdfa
14:04:23 <ivan> zakim, mute Aharon
14:04:23 <Zakim> Aharon should now be muted
14:04:36 <ivan> zakim, unmute Aharaon
14:04:36 <Zakim> sorry, ivan, I do not know which phone connection belongs to Aharaon
14:04:38 <tomayac> zakim, P24 is me
14:04:38 <Zakim> sorry, tomayac, I do not recognize a party named 'P24'
14:04:44 <ivan> zakim, ??P24 is ShaneM 
14:04:44 <Zakim> +ShaneM; got it
14:04:49 <tomayac> zakim, 24 is me
14:04:49 <Zakim> sorry, tomayac, I do not recognize a party named '24'
14:05:00 <ivan> zakim, Aharon is tomayac
14:05:00 <Zakim> +tomayac; got it
14:05:06 <ivan> zakim, unmute tomayac 
14:05:06 <Zakim> tomayac should no longer be muted
14:05:12 <Zakim> + +1.781.273.aacc
14:05:25 <MacTed> Zakim, aacc is OpenLink_Software
14:05:25 <Zakim> +OpenLink_Software; got it
14:05:29 <MacTed> Zakim, OpenLink_Software is temporarily me
14:05:29 <Zakim> +MacTed; got it
14:06:17 <manu> Topic: Plan for RDFa 1.1 Progress
14:06:29 <gkellogg> ivan: TAG updates, we have been asked by "other people" to wait until next week or the week after, where they may be a schema.org announcement.
14:06:48 <gkellogg> … awaiting answers until end of next week, if we don't have answers by then, we'll see where the TAG stands on the issue.
14:07:06 <Zakim> + +3539149aadd
14:07:14 <gkellogg> … next option is to go with the TAG group only if search engine people and the rest of the people that have adopted RDFa/Microdata/Microformats are a part of it.
14:07:22 <manu> zakim, aadd is Knud
14:07:22 <Zakim> +Knud; got it
14:07:24 <Knud> Knud has joined #rdfa
14:07:29 <manu> zakim, mute Knud
14:07:29 <Zakim> Knud should now be muted
14:07:40 <gkellogg> … without the search engines, then whatever the TAG does would be ignored by HTML5 WG.
14:08:26 <gkellogg> … my personal opinion is that if the TAG is ignored, then we must finish RDFa 1.1 with discussed changes and accept that there will be two formats around HTML 5 (Microdata and RDFa)
14:09:24 <gkellogg> manu: so it seems the plan going forward is to wait for schema.org issues to resolve themselves, which they might, otherwise get search engine companies involved with all other companies deploying RDFa/Microdata, otherwise, TAG group won't happen and we will go forward with both RDFa and Microdata.
14:09:33 <tomayac> is everyone aware of this blog post: http://blog.schema.org/2011/07/on-june-2-nd-we-announced-collaboration.html
14:13:56 <niklasl> q+
14:14:06 <manu> ack niklasl
14:14:08 <niklasl> Anyone seen this? http://www.jenitennison.com/blog/node/162
14:14:11 <ivan> ack niklasl 
14:14:15 <ShaneM> q+ to ask about timeline
14:15:03 <gkellogg> ivan: This is Jeni's private opinion, not the TAG's position.
14:15:36 <manu> ack ShaneM
14:15:36 <Zakim> ShaneM, you wanted to ask about timeline
14:15:50 <gkellogg> shanem: we're already way past our timeline, what is it?
14:17:47 <gkellogg> ivan: W3C and TAG hopes to have a plan in a couple of weeks.
14:17:49 <gkellogg> manu: It's been a "couple of weeks" for a couple of weeks.
14:18:38 <manu> q+ to discuss a likely timeline
14:18:50 <gkellogg> ivan: Regardless, recent technical discussions will require another LC.
14:18:55 <manu> ack manu
14:18:55 <Zakim> manu, you wanted to discuss a likely timeline
14:19:38 <gkellogg> manu: My opinion is that TAG group won't happen because either Google won't be interested in participating, or Ian Hickson (the editor of Microdata) will just take the Microdata spec and publish it via the WHAT WG.
14:19:52 <gkellogg> … bottom line is that we continue with current the direction of the technical work on RDFa 1.1 Core, do another Last Call, then a Candidate Rec and then continue onward toward REC.
14:22:47 <gkellogg> manu: other issue is that the TAG announcement is causing some of the RDFa people to backpedal because there is this perception that RDFa 1.1 could be completely killed off.
14:23:00 <gkellogg> … EPub folks are worried that RDFa is "at risk".
14:23:42 <gkellogg> … I suggested that they shouldn't make that assumption, but they are completing next week and are worried that they can't reference a spec that is in the state that RDFa and Microdata are in.
14:23:54 <gkellogg> … they are now discussing the notion that they may take out the reference to the RDFa spec.
14:24:15 <gkellogg> … result is that the whole state of flux is causing uncertainty in the market - the public is becoming confused about the future of RDFa and Microdata because we haven't been sending a consistent message.
14:25:05 <gkellogg> … We must start broadcasting a message about the RDFa 1.1 work moving forward and be more assertive about the future of RDFa.
14:29:55 <gkellogg> ivan: we should finalize RDFa 1.1 Core ASAP.
14:30:21 <gkellogg> … recent group descriptions put weeks of work ahead of us, we should get on with it.
14:30:40 <gkellogg> … removing @profile and changes to @vocab will create weeks, not days of work.
14:30:54 <gkellogg> manu: in parallel, we should take public perception into consideration and ensure that people know that RDFa 1.1 has a future and is moving forward.
14:31:12 <tinkster> The recent @vocab proposal is actually what I suggested way back when we were introducing @vocab.
14:31:14 <tinkster> http://lists.w3.org/Archives/Public/public-rdfa-wg/2010Mar/0174.html
14:32:09 <gkellogg> manu: So, we're going to focus on the technical work and getting RDFa 1.1 Core spec into a solid Candidate REC draft. We'll position a solid public message about RDFa 1.1 in parallel.
14:32:28 <manu> Topic: Vocabulary Expansion Proposal
14:32:32 <manu> http://lists.w3.org/Archives/Public/public-rdfa-wg/2011Aug/0007.html
14:33:07 <gkellogg> ivan: recent mail slightly modifies it
14:33:32 <gkellogg> manu: a couple of comments on the proposal - RDF/XML and TURTLE requirement and putting rdfa:vocab declarations into the default graph.
14:33:44 <gkellogg> ivan: that's a different feature, somewhat independent.
14:34:33 <gkellogg> ivan: The overall goal of the vocab expansion proposal is that dereferencing the @vocab URI yields a small ontology which we can then post-process using SemWeb tools to enhance default graph.
14:34:49 <gkellogg> … it allows for subProperty/subClass to enhance default graph.
14:35:03 <gkellogg> … it ensures work we need to do is as small as possible.
14:35:20 <gkellogg> … core RDF people have defined semantics and we should refer to them.
14:36:09 <gkellogg> … refer to RDF semantics instead of our own default graph expansion rules - use a restricted version of RDFS (subclass, sub property, …)
14:36:32 <gkellogg> … RDFS has set of informal, but well documented, set of rules.
14:36:52 <gkellogg> … implementation indicates that it seems to work.
14:37:22 <manu> q+ to discuss SHOULD for RDF/XML/TURTLE and rdfa:vocab being in default graph
14:37:36 <niklasl> q+
14:37:49 <gkellogg> … recent change indicates RDFa processors MAY remove original ontology triples from default graph.
14:38:37 <gkellogg> … another section on if RDFa processor performs exponsion or not. By default, not, and RDFa processors are not required to perform expansion.
14:38:51 <manu> ack manu
14:38:51 <Zakim> manu, you wanted to discuss SHOULD for RDF/XML/TURTLE and rdfa:vocab being in default graph
14:38:55 <gkellogg> .. Cleanup of work by niklasl & gkellogg
14:39:31 <gkellogg> manu: I probably won't implement RDF/XML and Turtle, even though it is a SHOULD.
14:39:42 <gkellogg> … probably won't implement @vocab expansion.
14:40:08 <gkellogg> ivan: text doesn't yet pass "Shane test". However, a conformant processor does not have to perform expansion.
14:40:39 <gkellogg> … if a processor implements extension, then it MUST accept RDFa, SHOULD accept RDF/XML, Turtle, ...
14:40:56 <gkellogg> manu: still disagree with SHOULD. Every other RDF format should be a MAY.
14:41:08 <manu> RDFa processor MUST accept an RDF graph serialized in RDFa, and MAY accept other serialization formats of RDF.
14:42:11 <gkellogg> ivan: from position of author of @vocab file, I would need to write down an RDF ontology. 90% of authors would likely write down ontology in Turtle.
14:42:33 <gkellogg> … Having to author in RDFa is not important for them.
14:42:43 <gkellogg> q+ to comment on Turtle/RDFa
14:43:08 <gkellogg> manu: really need a human readable document to describe @vocab - it must be a best practice.
14:43:21 <gkellogg> … we should lead people to a best practice.
14:43:31 <niklasl> my view - vocab *processing* is beyond the RDFa processor.
14:44:00 <gkellogg> manu: we also have a processor graph, perhaps we should use it for @vocab triples.
14:44:19 <gkellogg> … they might not follow the default graph then.
14:44:46 <gkellogg> ivan: let's not conflate issues.
14:44:48 <manu> ack niklasl
14:45:28 <gkellogg> niklasl: my POV is that the processing vocab is beyond what an RDFa processor should do.
14:45:47 <gkellogg> … if you need semantic information, it should be up to RDF consumer/reuser
14:46:11 <gkellogg> … we also don't know the context, and it places a "contract" ambiguity for authors
14:46:22 <gkellogg> … if they publish an @vocab, when should it be used?
14:46:37 <ivan> q+
14:46:43 <gkellogg> … we could leave spec outside RDFa spec, but there could be a contract between publishers and consumers
14:46:52 <manu> q+ to say that if we don't define it, people won't do it.
14:47:08 <gkellogg> … many vocals already use subClass/subProperty, wouldn't expect to have vocabulary fully expanded.
14:47:35 <gkellogg> … why concept of proxyProperty/proxyClass was designed, to constrain the expansion and simplify authoring.
14:47:41 <gkellogg> … could be defined outside of RDFa.
14:47:44 <manu> ack gkellogg
14:47:44 <Zakim> gkellogg, you wanted to comment on Turtle/RDFa
14:48:31 <manu> gkellogg: Going back to SHOULD for RDF/XML and TURTLE - from a potential vocab authors perspective - I would use TURTLE - getting to RDFa is pretty easy from TURTLE. Getting those triples turned into HTML+RDFa is fairly easy.
14:48:59 <manu> gkellogg: It would be nice to be able to transform a TURTLE document into RDFa - RDF/XML and TURTLE should be a MAY.
14:49:15 <gkellogg> ivan: won't fight on SHOULD/MAY, he'll take group consensus.
14:49:19 <manu> ack ivan
14:50:01 <manu> I think that we should be very careful about what we think is "easy" - converting TURTLE to RDFa is /easy/ once you've written the code - but writing the code is difficult.
14:50:28 <gkellogg> … disagree with niklasl; if only thing RDFa processor does is to produce default graph with vocal URIs, the proxy vocal will, in effect, produce an expansion simiar to RDFS.
14:50:32 <manu> Meaning - it's easy for Gregg to write that code - but very difficult for most Web devs to write that code.
14:51:04 <gkellogg> … today, in practice, this would not happen, we don't know what are predicates that come from RDFa and which are there as full-blown URIs or CURIEs.
14:51:22 <gkellogg> … theoretically, niklasl is right, but in practice it wouldn't be used.
14:51:33 <gkellogg> … leaving us without a replacement for @profile.
14:52:03 <gkellogg> … by putting it (optionally) in the document, we make clear what the intent is, even for people not implementing expansion.
14:52:34 <gkellogg> … it becomes fairly easy or straightforward to implement RDFs expansion in a standalone fashion, helping to ensure that it will be implemented.
14:53:04 <gkellogg> … big value to having text in the spec, vs. as a separate doc.
14:53:29 <gkellogg> niklasl: not sure that not expanding is up to the user
14:53:40 <manu> q?
14:53:57 <gkellogg> … it will depend on the usage of the RDF produced, we'd rather that it re-use terms from (e.g.) FOAF & GR.
14:54:16 <gkellogg> ivan: DERI has started to do this.
14:54:45 <gkellogg> … what Schema.rdfs.org people did is pretty much this process for schema.org.
14:55:06 <gkellogg> … there will be a difference between various RDFa processors.
14:55:33 <gkellogg> … by default you don't do it, but there is a standard way to turn it on for processors that implement.
14:56:19 <gkellogg> niklas: this will mean that the use of @vocab will be the signal to say that here is something that you should use.
14:56:55 <gkellogg> … one problem, if you use FOAF, my original idea was to define proxy concept and use RDFS semantics rather than using RDFS directly.
14:57:41 <gkellogg> … I wouldn't necessarily like to have all properties listed in an @vocab document expanded. proxy semantics allows the vocal author to be more specific about which should be expanded.
14:57:46 <niklasl> consider - https://gist.github.com/1092350
14:58:07 <Zakim> -tomayac
14:58:08 <ShaneM> I agree that it would be wrong to remove the original triple
14:58:25 <gkellogg> ivan: original RDFS intent is only one that can be relied upon.
14:58:41 <gkellogg> … removing an original triple would be wrong, only adding new triples is acceptable.
14:59:13 <gkellogg> … we must have original triples so that a user has something to rely upon.
14:59:24 <niklasl> https://github.com/niklasl/rdf-sparql-lab/blob/master/curation/examples/vocab_map.ttl
14:59:33 <tinkster> http://lists.w3.org/Archives/Public/public-rdfa-wg/2010Mar/0174.html
14:59:34 <gkellogg> q+ to talk about diff between RDFS and PRoxy
15:01:54 <gkellogg> manu: is this called "proxy vocab feature" or something else.
15:02:22 <gkellogg> ivan: in my terminology, it's not a proxy. originally @vocab was just a URI expansion.
15:02:49 <gkellogg> … perhaps "graph expansion" rather than "triple expansion".
15:03:27 <gkellogg> shanem: academically appropriate terms doesn't help larger audience. Use marketing principles when naming.
15:04:04 <gkellogg> MacTed: pithy names turn into term overload issues. names must be chosen carefully.
15:04:08 <gkellogg> manu: Let's go with what we have right now and change the name later if we come up w/ something better.
15:04:14 <manu> ACTION: Niklas to author spec text for the Vocabulary Expansion mechanism with help from Gregg and Shane.
15:04:14 <trackbot> Sorry, couldn't find user - Niklas
15:04:21 <manu> ack manu
15:04:24 <manu> ack gkellogg
15:04:36 <manu> ACTION - Niklas to author spec text for the Vocabulary Expansion mechanism with help from Gregg and Shane.
15:04:36 <trackbot> Sorry, couldn't find user - -
15:04:40 <Zakim> manu, you wanted to say that if we don't define it, people won't do it.
15:04:48 <manu> New ACTION: Niklas to author spec text for the Vocabulary Expansion mechanism with help from Gregg and Shane.
15:04:54 <manu> ack gkellogg
15:04:59 <Zakim> gkellogg, you wanted to talk about diff between RDFS and PRoxy
15:05:12 <manu> gkellogg: We should just use RDFS instead of re-inventing the wheel...
15:05:39 <Zakim> -MacTed
15:05:45 <gkellogg> ivan: Let's switch to the discussion of @vocab triples added to graph
15:05:47 <manu> Topic: rdfs:vocab in the default graph
15:06:24 <gkellogg> … if you have processor that can't do @vocab expansion, adding @vocab triples allows a separate post-processor to perform expansion.
15:06:48 <gkellogg> … adding information into the graph allows another processor to pick up the expansion.
15:07:05 <gkellogg> … whether these triples are added to default graph or the processor graph is the issue.
15:07:15 <manu> +1 to adding rdfa:vocab info to processor output
15:07:20 <gkellogg> … first question, does this make sense.
15:07:22 <gkellogg> +1
15:07:27 <ShaneM> +1 to add to the output
15:07:42 <niklasl> +0 right now..
15:08:01 <gkellogg> ivan: default vs. processor graph ...
15:08:23 <gkellogg> … reason still in favor of default graph, because processor graph has been used for just warnings and errors.
15:08:30 <manu> q+ to say what he uses the processor graph for
15:08:45 <niklasl> +1 for processor graph
15:08:52 <gkellogg> … for users that don't care, might switch off processor graph.
15:09:01 <gkellogg> … still in favor of default graph.
15:09:05 <gkellogg> +1 for default graph
15:09:15 <manu> ack manu
15:09:15 <Zakim> manu, you wanted to say what he uses the processor graph for
15:09:52 <gkellogg> manu: I use the processor graph when triples are generated or prefixes declared - for warnings, errors and informational parser output.
15:10:22 <gkellogg> … I emit a triple for every time xmlns: and @prefix is hit by processor, using proprietary vocabulary.
15:11:05 <gkellogg> q+ to talk about use of processor graph in Ruby
15:11:23 <gkellogg> manu: application will decide if it wants @vocab triples expanded.
15:11:38 <gkellogg> … application registers callbacks for when triples are generated for the default graph or for the processor graph.
15:12:06 <gkellogg> … if the application wants to, (rdfa processing in step 1, vocab in step 2)
15:12:17 <gkellogg> … it can record information for use later.
15:12:28 <niklasl> q+ re. action on or preservation of vocab
15:12:38 <ivan> q+
15:12:44 <gkellogg> … downside is that the default graph doesn't know how to generate triples, but this leaves it up to application. The application should decide what to do with the @vocab triples.
15:12:54 <manu> ack gkellogg
15:12:54 <Zakim> gkellogg, you wanted to talk about use of processor graph in Ruby
15:12:59 <niklasl> q+ to mention action on or preservation of vocab
15:13:11 <ivan> q later
15:13:36 <manu> gkellogg: I also use the processor graph for a lot of information - debug output and quite a bit of other information. There won't be many rdfa:vocab triples - so why not just put it in the default graph.
15:13:39 <manu> ack niklasl
15:13:39 <Zakim> niklasl, you wanted to mention action on or preservation of vocab
15:14:07 <gkellogg> niklasl: in favor of having action by processor.
15:14:26 <manu> ack ivan
15:14:29 <gkellogg> … if you don't want to, you'll still implicitly have reference to data to use for post-processing, using follow-your-nose.
15:14:56 <gkellogg> ivan: I also put debug information in the processor graph.
15:15:18 <manu> q+ to say that I'm not talking about one application
15:15:27 <gkellogg> … what manu implies is that he has one single application that does whole job, relying on RDFa processor. that application can decide to turn expansion on.
15:15:35 <Zakim> -Knud
15:16:05 <gkellogg> … the point is that a viable setup is that someone extracts RDF from RDFa page and from that point on, that RDF graph is exchanged from one app to the other, meaning that that RDF graph can be sent to an application that doesn't have access to original HTML5.
15:16:41 <gkellogg> … if you want another application to handle expansion is to add entire processor graph, which may contain much irrelevant information.
15:17:10 <gkellogg> … the prefix information manu referred to may be valuable to the application, but is unimportant from an RDF content point of view.
15:17:17 <gkellogg> … still in favor of default graph.
15:18:18 <gkellogg> … what niklasl said would seem to take us back to an earlier position requiring processors to need to perform expansion on many vocabularies not originally referenced.
15:18:34 <gkellogg> manu: other issue with default graph is that they are like stylesheet triples - useless to most people that don't care about that particular application (stylesheets are useless to RDF folks... RDF vocabulary expansion is useless to people like schema.org)
15:18:53 <gkellogg> ivan: not so, prefix triples are like stylesheet, but @vocab triples have deep semantic value.
15:19:13 <gkellogg> … those triples help applications to bind the predicates or classes to vocabularies defined elsewhere; huge difference.
15:19:27 <gkellogg> manu: yes, @vocab triples are of huge use for RDF apps that care about it.
15:19:45 <gkellogg> … but for all other apps, they're effectively like stylesheet triples.
15:19:52 <gkellogg> … don't feel too strongly on this - could go either way. 
15:20:15 <gkellogg> … From design perspective it's less related to semantic content of document and more like a stylesheet for RDF apps.
15:20:27 <gkellogg> ivan: default graph would contain all important information in RDFa graph.
15:20:38 <gkellogg> … in that information is @vocab - which is important.
15:20:59 <gkellogg> … @prefix triples don't have same deep semantic information, they are beautifying.
15:21:20 <gkellogg> manu: saying that @vocab attribute generates an important triple about the document. Not just processing-related, but a triple that has actual semantic value against the document... it signifies, in part, what the document is trying to express. That line of argumentation works for me.
15:21:36 <gkellogg> … use this triple and get even more meaning from document.
15:22:22 <gkellogg> niklasl: not convinced. understand principle. A bit uncomfortable with overloading @vocab; we're going back to @profile semantics.
15:22:37 <gkellogg> … If we had the bandwidth, we could define @profile to do this.
15:22:46 <gkellogg> ivan: been there, done that.
15:23:22 <gkellogg> … understand @profile arguments, could go either way.
15:23:34 <gkellogg> … there were some very serious use cases which lead to concept of @profile.
15:23:59 <gkellogg> … it seems @vocab strategy can cover these use cases.
15:24:15 <gkellogg> … people where care about RDF mapping can use RDFS.
15:24:33 <gkellogg> … use case covered without downside of @profile, can't forget about original use cases.
15:24:53 <gkellogg> manu: does @vocab lead to triples in the default graph?
15:24:59 <gkellogg> +1 to default graph
15:25:04 <ivan> +1 default
15:25:06 <manu> +1 to default graph
15:25:13 <niklasl> +0
15:25:26 <gkellogg> manu: proceed under that assumption, pending feedback from rest of the group.
15:26:29 <niklasl> q+ to ask about my membership :)
15:26:33 <gkellogg> ivan: on use of SCM tools, we should work in W3C CVS, not GitHub - Gregg, send me your key. We'll get Niklas' key if he ends up being accepted as an Invited Expert - still processing his paperwork.
15:28:25 <Zakim> -ShaneM
15:28:31 <Zakim> -scor
15:35:45 <Zakim> -gkellogg
15:37:05 <Zakim> -manu
15:37:07 <Zakim> -Ivan
15:37:09 <Zakim> -niklasl
15:37:15 <niklasl> niklasl has left #rdfa
# SPECIAL MARKER FOR CHATSYNC.  DO NOT EDIT THIS LINE OR BELOW.  SRCLINESUSED=00000298