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:27 <manu> Agenda: http://lists.w3.org/Archives/Public/public-rdfa-wg/2011Aug/0019.html
13:52:33 <manu> manu has changed the topic to: Agenda: http://lists.w3.org/Archives/Public/public-rdfa-wg/2011Aug/0019.html (manu)
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:55:58 <tinkster> I seem to no longer be an RDFa WG member. When did this happen?
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:22 <tinkster> I new the name had changed - didn't realise that I had to renew. Is it still possible?
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:20 <tinkster> Ivan?
13:59:23 <Zakim> + +1.781.866.aabb
13:59:44 <tinkster> Also, is it OK if I sit in IRC here in the mean time?
13:59:47 <Zakim> +??P12
13:59:52 <ivan> of course
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:05:31 <MacTed> :-)
14:06:17 <manu> Topic: Status of TAG Note
14:06:29 <gkellogg> ivan: TAG updates, asked by "other people" to wait until next week.
14:06:48 <gkellogg> … awaiting answers until EO next week, then go to TAG.
14:07:06 <Zakim> + +3539149aadd
14:07:14 <gkellogg> … next hurdle: go with TAG group only if search engine people are 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 search engines, then whatever the TAG does would be ignored by HTML5 WG.
14:08:26 <gkellogg> … personal opinion, then we must finish RDFa 1.1 with discussed changes and accept that there will be two formats around HTML 5 (MD and RDFa)
14:09:24 <gkellogg> manu: strategy going forward: wait for schema.org issues to move forward, otherwise get search engine companies involved, otherwise, TAG group won't happen and go forward with both REQs.
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> 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.
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: we hope to have a plan in a couple of weeks.
14:18:38 <manu> q+ to discuss a likely timeline
14:18:50 <gkellogg> … récent 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: opinion is that TAG group won't happen.
14:19:52 <gkellogg> … we continue with current direction.
14:22:47 <gkellogg> manu: other issue is RDFa people backpedaling.
14:23:00 <gkellogg> … EPub folks are worried that RDFa is "at risk".
14:23:42 <gkellogg> … suggested that they shouldn't make that assumption, but they are completing next week and are worried that they can't ref a spec in transition.
14:23:54 <gkellogg> … probably take out reference to RDFa spec.
14:24:15 <gkellogg> … result is that the whole state of flux is causing uncertaintyy in the market.
14:24:37 <gkellogg> s/uncertaintyy/uncertainty/
14:25:05 <gkellogg> … We must produce a message about RDFa 1.1 working moving forward and be more assertive about a future for 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: we should take public perception into consideration and move forward.
14:31:12 <tinkster> 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: focus on technical work and get RDFa 1.1 Core spec in solid spec and position public message in parallel.
14:32:28 <manu> Topic: Vocabulary Proxy 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: couple of mods, creation of @vocab putting declarations into default graph
14:33:44 <gkellogg> ivan: a different feature, somewhat independent.
14:34:33 <gkellogg> ivan: agreed that overall goal is that dereferencing @vocab URI yields a small ontology and fallback on SemWeb tools to enhance default graph.
14:34:49 <gkellogg> … allows for subProperty/subClass to enhance default graph.
14:35:03 <gkellogg> … wants to ensure work we need to do is as small as possible.
14:35:20 <gkellogg> … want to say that core RDF people have defined semantics and we should refer to it.
14:36:09 <gkellogg> … refer to RDF semantics, but instead of expanding default graph, but 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: 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.
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: POV is processing vocal 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> nilasl: 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> … pithy names turn into term overload issues. names must be chosen carefully.
15:04:08 <gkellogg> manu: change later.
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:20 <MacTed> s/…/MacTed/
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:40 <niklasl> manu: I'm not a member yet, right?
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: 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 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 added to default or processor graphs is 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> ah: +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: uses processor graph when triples are generated or prefixes declared.
15:10:22 <gkellogg> … emit a triple for every time xmlns: and @prefix is hit by processor.
15:10:47 <gkellogg> … 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 into the default 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.
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: also puts debug information in 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.
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: huge for RDF apps that care about it.
15:19:45 <gkellogg> … effectively like stylesheet triples.
15:19:52 <gkellogg> … don't feel too strongly. 
15:20:15 <gkellogg> … From design perspective it's less related to semantic content of document and like stylesheet.
15:20:27 <gkellogg> ivan: default graph would contain all important information in RDFa graph.
15:20:38 <gkellogg> … that information (@vocab) 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 a triple. Not just processing, what document is trying to express.
15:21:26 <gkellogg> .. convincing argument.
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 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 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, should work in CVS, not GitHub.
15:27:00 <gkellogg> nilasl and gkellogg should sent SSH keys to get access to the CVS archive sub-tree
15:27:49 <gkellogg> … W3C website is essentially a CVS archive; committing to CVS causes it to appear on the web.
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
15:42:10 <Zakim> disconnecting the lone participant, SebastianGermesin, in SW_RDFa()10:00AM
15:42:13 <Zakim> SW_RDFa()10:00AM has ended
15:42:14 <Zakim> Attendees were gkellogg, manu, +68185775aaaa, SebastianGermesin, Ivan, +1.781.866.aabb, niklasl, scor, ShaneM, tomayac, +1.781.273.aacc, MacTed, +3539149aadd, Knud
15:45:51 <ShaneM> ShaneM has left #rdfa
17:42:23 <Zakim> Zakim has left #rdfa
18:32:21 <ShaneM> ShaneM has joined #rdfa
18:33:30 <ShaneM> ShaneM has left #rdfa
18:48:23 <manu> trackbot,bye
18:48:26 <manu> trackbot, bye
18:48:26 <trackbot> trackbot has left #rdfa
18:48:28 <manu> rrsagent, bye
18:48:28 <RRSAgent> I see 1 open action item saved in http://www.w3.org/2011/08/11-rdfa-actions.rdf :
18:48:28 <RRSAgent> ACTION: Niklas to author spec text for the Vocabulary Expansion mechanism with help from Gregg and Shane. [1]
18:48:28 <RRSAgent>   recorded in http://www.w3.org/2011/08/11-rdfa-irc#T15-04-14