Chatlog 2010-10-21

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

13:59:48 <RRSAgent> RRSAgent has joined #rdfa
13:59:48 <RRSAgent> logging to http://www.w3.org/2010/10/21-rdfa-irc
13:59:50 <trackbot> RRSAgent, make logs world
13:59:50 <Zakim> Zakim has joined #rdfa
13:59:52 <trackbot> Zakim, this will be 7332
13:59:52 <Zakim> ok, trackbot; I see SW_RDFa()10:00AM scheduled to start in 1 minute
13:59:53 <trackbot> Meeting: RDFa Working Group Teleconference
13:59:53 <trackbot> Date: 21 October 2010
14:00:11 <Zakim> SW_RDFa()10:00AM has now started
14:00:14 <Knud> Knud has joined #rdfa
14:00:18 <Zakim> +ShaneM
14:00:39 <Zakim> + +44.785.583.aaaa
14:00:41 <manu1> zakim, code?
14:00:41 <Zakim> the conference code is 7332 (tel:+1.617.761.6200 tel:+33.4.26.46.79.03 tel:+44.203.318.0479), manu1
14:00:42 <tinkster> Zakim, I am aaaa
14:00:44 <Zakim> +tinkster; got it
14:00:51 <tinkster> zakim, mute me
14:00:51 <Zakim> tinkster should now be muted
14:00:59 <Steven> Steven has joined #rdfa
14:01:10 <Steven> zakim, who is here?
14:01:10 <Zakim> On the phone I see ShaneM, tinkster (muted)
14:01:12 <Zakim> On IRC I see Steven, Knud, Zakim, RRSAgent, ShaneM, tinkster, manu1, markbirbeck, trackbot, nathan
14:01:17 <Steven> zakim, dial steven-617
14:01:17 <Zakim> ok, Steven; the call is being made
14:01:18 <Zakim> +Steven.a
14:01:20 <Zakim> +[IPcaller]
14:01:50 <manu1> zakim, I am [IPcaller]
14:01:50 <Zakim> ok, manu1, I now associate you with [IPcaller]
14:02:49 <Zakim> + +35387689aabb
14:02:51 <manu1> zakim, who is on the call?
14:02:51 <Zakim> On the phone I see ShaneM, tinkster (muted), Steven.a, [IPcaller], +35387689aabb
14:03:01 <ShaneM> Present: Shane, Toby, Steven, Manu, MarkB, Knud, Nathan
14:03:03 <ShaneM> Regrets: Ivan, BenA, Benjamin
14:03:04 <ShaneM> Scribe: Shane
14:03:06 <ShaneM> scribenick: ShaneM
14:03:20 <manu1> Agenda: http://lists.w3.org/Archives/Public/public-rdfa-wg/2010Oct/0187.html
14:03:25 <Knud> zakim, I am aabb
14:03:25 <Zakim> +Knud; got it
14:03:26 <Zakim> +??P20
14:03:27 <manu1> zakim, who is on the call?
14:03:27 <Zakim> On the phone I see ShaneM, tinkster (muted), Steven.a, [IPcaller], Knud, ??P20
14:03:32 <nathan> zakim, i am ?
14:03:34 <Zakim> +nathan; got it
14:03:39 <manu1> zakim, who is on the call?
14:03:40 <Zakim> On the phone I see ShaneM, tinkster (muted), Steven.a, [IPcaller], Knud, nathan
14:03:51 <Knud> zakim, mute me
14:03:54 <Zakim> Knud should now be muted
14:03:56 <Zakim> +??P19
14:03:57 <manu1> zakim, [IPcaller] is me
14:03:58 <Zakim> +manu1; got it
14:04:00 <manu1> zakim, who is on the call?
14:04:00 <Zakim> On the phone I see ShaneM, tinkster (muted), Steven.a, manu1, Knud (muted), nathan, ??P19
14:05:38 <ShaneM> TOPIC: Alternate proposals for RDFa Profile format
14:05:51 <ShaneM> Mail is at http://lists.w3.org/Archives/Public/public-rdfa-wg/2010Oct/0238.html
14:05:56 <ShaneM> This is the current spec: http://www.w3.org/2010/02/rdfa/sources/rdfa-core/
14:06:14 <ShaneM> markbirbeck: big objection is to using RDF as the format for the Profile.
14:07:12 <ShaneM> markbirbeck: we already have a prefix mapping syntax; let's just take that to an external file.
14:07:44 <ShaneM> ... manu mentioned we would then need yet another parser.  But that's not the case.  Clearly an RDFa processor already has a parser for this format, since they must parse @prefix
14:07:57 <ShaneM> ... format is very straigthfroward.
14:08:56 <ShaneM> ... architecturally - the parsing of profiles would be done at a logical layer of the processor.  You would not need to have the full stack in place.  And the bottom of the architecture would not rely upon having the whole stack in place.
14:09:42 <ShaneM> ... The syntax needs a way to express the default vocabulary.  Proposal suggests using ':'.  Syntax needs a way to express terms.  Proposal suggests NCName without a trailing colon.
14:11:18 <ShaneM> markbirbeck: Second proposal is to use RDFa but use @prefix, @vocab, and @xmlns attributes on the html element to define the aspects of the RDFa Profile
14:12:04 <ShaneM> ... Ivan asked why only on html element.  No real reason, but we would need to say that the usual pushing and popping of definitions would not occur.  Something else would need to happen.
14:12:21 <ShaneM> ... this approach would not require a full RDFa parser and would not require any specialized triple parsing.
14:12:35 <tinkster> I also could live with first proposal, but don't especially like the second one.
14:13:04 <ShaneM> Steven: I like the second proposal because it uses the same notation we already have.
14:13:10 <manu1> q+ to discuss preference over current proposal
14:13:29 <tinkster> the second one means that third parties could use my non-profile RDFa documents as if they were a profile, which i might not like.
14:14:01 <ShaneM> manu1: we really need to know if each person prefers what is already in the spec, or would prefer one of these options.
14:14:52 <nathan> q+ to discuss option 2
14:14:54 <ShaneM> ... if we go with proposal 2, we will need a way of defininig terms - like a term attribute
14:14:59 <manu1> ack manu1
14:14:59 <Zakim> manu1, you wanted to discuss preference over current proposal
14:15:13 <ShaneM> markbirbeck: the current proposal says that you can do term definitions in @prefix
14:15:17 <manu1> ack nathan
14:15:17 <Zakim> nathan, you wanted to discuss option 2
14:15:43 <manu1> zakim, who is making noise?
14:15:52 <ShaneM> Nathan: If we go for option 2, I am not really following why there is any benefit to it over using the current mechanism.
14:15:53 <Zakim> manu1, listening for 10 seconds I heard sound from the following: ShaneM (35%), manu1 (5%), nathan (4%)
14:15:59 <manu1> zakim, mute shanem
14:15:59 <Zakim> ShaneM should now be muted
14:16:10 <ShaneM> zakim, unmute ShaneM
14:16:10 <Zakim> ShaneM should no longer be muted
14:16:56 <ShaneM> markbirbeck: there is no RDFa processor needed.  You need a DOM.   Requiring an RDFa processor will narrow the range of applications where this can be used.
14:17:08 <ShaneM> ... you need a full RDFa Processor in order to process profiles.
14:18:06 <ShaneM> Nathan: I don't really follow entirely.  The first proposal lies with me a little better.  If we are going to take it out and simplify it, we should simplify it all the way.
14:19:43 <ShaneM> markbirbeck: I agree.  However, just to explain.  You might have a stack that does processing as a set of modules.  Nothing in the architecture to date has required that the processor evaluate the triples it is extracting.  So introducing RDFa Profiles as RDFa means that there is a major new requirement on the processor.
14:20:29 <ShaneM> Nathan: Okay - I understand now.  I don't see that as a problem.  I (perhaps wrongly) assume that the stack will always be there in an RDFa Processor anyway.
14:21:14 <manu1> q+ to say that we don't restrict the RDFa Profile file format
14:21:35 <ShaneM> markbirbeck: You're not wrong necessarily.  But we already have people like OGP saying that they are only looking at meta elements in the head.  So people are subsetting the structure already.
14:21:37 <manu1> ack manu1
14:21:37 <Zakim> manu1, you wanted to say that we don't restrict the RDFa Profile file format
14:21:56 <ShaneM> Steven: Hang on - people are using a small part of it.  That doesn't mean they aren't implementing all of it.
14:22:51 <nathan> q+ to clarify point on existing profiles
14:23:11 <nathan> q-
14:23:46 <ShaneM> manu1: You can define things in other formats if you want - you are just required to also have a version in RDFa.
14:23:53 <ShaneM> markbirbeck: no - the spec doesn't allow this.
14:24:10 <ShaneM> ShaneM: Yes, it does... It says "They may also be defined in other RDF serializations as well  (e.g., RDF/XML [RDF-SYNTAX-GRAMMAR] or Turtle [TURTLE])."
14:24:21 <ShaneM> ... oh.  wait.  no.  that does not permit, for example, proposal 1 nor proposal 2.
14:24:45 <ShaneM> manu1: Nathan, of the current text or the two new proposals, which do you really want?  
14:25:15 <manu1> q+
14:25:57 <ShaneM> Nathan: I would prefer to keep it the way it is but open it up to additional alternate formats (e.g. turtle).
14:26:01 <tinkster> I certainly already support RDFa, Turtle, N-Triples, RDF/XML and Talis' RDF/JSON format.
14:26:02 <manu1> ack manu1
14:26:31 <ShaneM> manu1: I agree with Nathan.  I prefer the way we are doing it in the current spec.  But I see no reason to limit alternate formats.
14:26:45 <tinkster> zakim, unmute me
14:26:45 <Zakim> tinkster should no longer be muted
14:27:06 <ShaneM> manu1: tinkster do you support these for profiles?
14:27:15 <ShaneM> tinkster: Yes - I support all those formats for profiles.
14:27:22 <ShaneM> manu1: What about non-RDF serializations?
14:27:52 <ShaneM> tinkster: Well... anything can be thought of as an RDF serialization...  Something that can be used with only limited types of data.
14:28:41 <ShaneM> markbirbeck: I don't know if that is true... when you create a RDF serialization you are saying that you want to support RDF using it.  Just because you can put on a special pair of glasses and interpret something as RDF doesn't mean it is really an RDF serialization.
14:29:05 <ShaneM> manu1: tinkster of the proposals which do you prefer?
14:29:11 <tinkster> zakim, mute me
14:29:11 <Zakim> tinkster should now be muted
14:29:33 <tinkster> #1: ivan's; #2 mark's flat text file; #3: mark's html format
14:30:02 <manu1> Shane: I prefer the text in the document today, however I would be happy to allow alternate non-RDF formats.
14:30:36 <manu1> Shane: The document says RDF serialization, I think it was a mistake to put it in there.
14:30:58 <nathan> q+
14:31:38 <ShaneM> markbirbeck: I disagree.  the text said 'RDF serialization' on purpose.
14:31:48 <manu1> Manu: I agree, it was a mistake to put it in there.
14:31:52 <ShaneM> manu1: No - it is a mistake.  You can do anything with the alternate formats.
14:32:32 <ShaneM> markbirbeck: This is not generic in the document.  There are lots of rules that seem to require it to be an RDF Serialization.
14:32:32 <manu1> ack nathan
14:32:48 <manu1> Shane: Mark, that sentence was there so you could do JSON.
14:33:52 <ShaneM> Nathan: I wanted to clarify... I think that the current document really really meant that alternate formats had to be an RDF serialization.  
14:34:38 <ShaneM> ... are we saying that we are going to loosen this up so much that you wouldn't need an RDF thing at all?
14:34:53 <ShaneM> markbirbeck: Yeah - it is not clear what this would mean if it were not RDF.
14:35:33 <ShaneM> Nathan: I cant see how we can loosen this up all the way.
14:35:41 <ShaneM> q+ to talk about alternate formats
14:35:52 <manu1> ack shanem
14:35:52 <Zakim> ShaneM, you wanted to talk about alternate formats
14:36:11 <ShaneM> ... requiring that alternates are in any format and it be magically interpreted seems challenging.
14:36:47 <manu1> Shane: The intent of that was not that every RDF processor would understand arbitrary formats, every RDFa Processor is required to understand the RDFa Profile (input format)
14:37:16 <manu1> Shane: If your implementation chose to support other formats, that's fine, great, go ahead - you can do that if you want.
14:37:20 <Knud> +1 what Shane is saying: the critical thing is the "must be defined in an approved RDFa Host Language", right?
14:37:30 <manu1> Shane: There is no requirement on an RDFa processor to understand all formats.
14:37:40 <ShaneM> Yes, Knud.
14:37:50 <Knud> zakim, unmute me
14:37:50 <Zakim> Knud should no longer be muted
14:38:11 <manu1> zakim, who is on the call?
14:38:11 <Zakim> On the phone I see ShaneM, tinkster (muted), Steven.a, manu1, Knud, nathan, markbirbeck
14:38:11 <ShaneM> Knud: I am happy with what is in the specification at the moment.
14:38:28 <ShaneM> ... I do see mark's potential problem with circularity.. but I don't see a big problem with that.
14:38:48 <ShaneM> ... if we are making any change at all, I would go with mark's first proposal.  I see no value in the second proposal.
14:38:58 <ShaneM> ... so my preference is to leave the spec alone.
14:39:11 <Knud> zakim, mute me
14:39:11 <Zakim> Knud should now be muted
14:39:24 <ShaneM> Steven: I am okay with leaving the spec alone.  I have no problem with proposal 2.
14:40:01 <ShaneM> ... there are two sorts of simple.  I am happier for an author to find it simpler than for the implementor.
14:40:51 <ShaneM> manu1: mark, would you like to say anything?  I am wondering if we can split this into two proposals.  Which of the three options do we prefer?  And should we loosen the text further about alternate formats?
14:40:58 <ShaneM> Shane: +1
14:41:40 <ShaneM> markbirbeck: Hearing steven's comments I think that my second  proposal is better.  
14:42:24 <ShaneM> ... the pure text approach requires more work for authors.  There is also an issue with the content type if looking at the first proposal.
14:42:28 <tinkster> n-triples uses text/plain :-(
14:42:37 <ShaneM> ... so I am now moving towards the second proposal.
14:43:53 <ShaneM> ... I think that the current text should not be an entry level.  The leap to create a profile for an RDFa author is wide using the current mechanism.  Proposal 2 has a much lower barrier to entry.
14:44:02 <ShaneM> ... the current text is off putting.
14:46:47 <nathan> q+ to add a quick note on marks comments
14:46:55 <manu1> q+ to mention issues
14:47:05 <ShaneM> markbirbeck: Can we also consider a 4th option: proposal 2 OR the current text?
14:47:08 <manu1> ack nathan
14:47:08 <Zakim> nathan, you wanted to add a quick note on marks comments
14:47:37 <tinkster> I think that in any case we need to specify at least one canonical format, for interop reasons.
14:47:51 <ShaneM> Nathan: I quite like the idea of offering the choice.
14:48:10 <manu1> ack manu1
14:48:10 <Zakim> manu1, you wanted to mention issues
14:48:17 <ShaneM> ... its great to be able to just pull in prefix mappings from another document.
14:49:07 <ShaneM> manu1: the problem with this is we also need to add @term - and that means we cannot close on this today.
14:49:12 <manu1> q+ to discuss other issues
14:49:24 <ShaneM> Nathan: Just forget about the terms.  Only grab the prefixes from the other document.
14:49:26 <manu1> ack manu1
14:49:26 <Zakim> manu1, you wanted to discuss other issues
14:50:22 <ShaneM> manu1: what happens if someone wants to use dcterms as a prefix in their RDFa Profile document?  It means that the prefix gets included in the collection even if the RDFa Profile author didn't intend it to be.
14:50:47 <ShaneM> ... there are potential knock-on effects from a decision like this.  We need to look at them before proceeding if we introduce that behavior.
14:51:04 <ShaneM> manu1: I am fine with offering the 4th choice.
14:51:42 <manu1> PROPOSAL: RDFa Working group prefers the flat-file text format as the primary mechanism for expressing RDFa Profiles.
14:52:02 <ShaneM> Shane: -1
14:52:05 <tinkster> +0
14:52:06 <nathan> -1
14:52:09 <manu1> -1
14:52:14 <Steven> -1
14:52:23 <Knud> should we give a +1 for every proposal we would support? Or only give one +1?
14:52:50 <Knud> +0
14:53:40 <ShaneM> mark voted +0
14:54:00 <markbirbeck> +0
14:54:05 <manu1> PROPOSAL: RDFa Working group prefers the usage of @prefix and @term in the RDFa Profile document to express prefix and term mappings.
14:54:45 <tinkster> -1 (I don't want people using profile="http://tobyinkster.co.uk/")
14:55:19 <markbirbeck> +1
14:55:21 <Knud> -1
14:55:29 <manu1> -1
14:55:30 <nathan> +0
14:55:34 <ShaneM> Shane: -1 (I don't want random prefixes to get included and I don't want real RDFa Profiles mis interpreted)
14:55:37 <Steven> +0
14:56:32 <manu1> PROPOSAL: RDFa Working group prefers the current text in the RDFa Core document as a way of expressing RDFa Profile document.
14:56:43 <manu1> PROPOSAL: RDFa Working group prefers the current text in the RDFa Core document as a way of expressing RDFa Profile documents.
14:56:45 <ShaneM> Shane: +1
14:56:47 <Steven> http://www.w3.org/TR/2010/WD-rdfa-core-20100803/#s_profiles
14:56:50 <tinkster> +1
14:57:02 <nathan> +1
14:57:05 <tinkster> ok, then +0.5
14:57:05 <Steven> +1
14:57:09 <Knud> +1
14:57:11 <markbirbeck> -1 (Don't like an RDF-only solution.)
14:57:39 <manu1> +1
14:59:30 <manu1> PROPOSAL: RDFa Working group prefers supporting the current text in the RDFa Core document in addition to @prefix and @vocab.
14:59:40 <tinkster> -1 too ambiguous
14:59:55 <manu1> PROPOSAL: RDFa Working group prefers supporting the current text in the RDFa Core document in addition to @prefix and @vocab on the HTML element.
15:00:02 <tinkster> -1
15:00:18 <Zakim> -tinkster
15:02:02 <ShaneM> Nathan: are we requiring that both must be supported? or are we requring that the current text be supported, but that someone MAY also support the @prefix and @vocab on the HTML element?
15:02:10 <ShaneM> markbirbeck: I am quite happy if we require it support both.
15:02:53 <ShaneM> Nathan: Do we then need another option?  
15:03:42 <ShaneM> manu1: I think that need to support both.  If we make it optional there would be interoperability issues.  If both are permitted then anyone can expressing profiles using @prefix and @vocab
15:03:56 <manu1> PROPOSAL: RDFa Working group prefers supporting the current text in the RDFa Core document in addition to @prefix and @vocab on the HTML element.
15:04:09 <manu1> -1
15:04:10 <ShaneM> Shane: -1 (without a different media type or announcement mechanism I wouldn't know as a processor implementor which format I was being handed)
15:04:10 <Steven> +0
15:04:11 <Knud> +0
15:04:13 <markbirbeck> +1
15:04:14 <tinkster> -1 still
15:04:19 <nathan> +0.5
15:04:42 <markbirbeck> @ShaneM: Simple...there would be no triples in one.
15:05:00 <manu1> RESOLVED: RDFa Working group prefers the current text in the RDFa Core document as a way of expressing RDFa Profile documents.
15:05:01 <ShaneM> manu1: It looks as if option 3 was preferred.  Anyone disagree?
15:05:57 <ShaneM> manu1: does anyone need to leave?
15:06:06 <ShaneM> Steven: I can't stay much longer?
15:06:21 <ShaneM> manu1: Do you have any objections to the proposed resolutions on the outstanding issues?
15:06:31 <ShaneM> Steven: Not sufficiently to get worked up about.
15:06:48 <ShaneM> manu1: Do you support going to last call with any changes that we agree to today?
15:06:50 <ShaneM> Steven: Yep.
15:06:50 <nathan> I have to leave in 5/10 minutes but am happy with all other issues (no strong preferences)
15:08:13 <manu1> PROPOSAL: Provide language in the RDFa Core spec to allow non-RDF serializations for RDFa Profile documents.
15:08:17 <ShaneM> My proposed language is "They may also be defined in formats as well  (e.g., JSON, RDF/XML [RDF-SYNTAX-GRAMMAR] or Turtle [TURTLE])."
15:08:26 <ShaneM> s/formats/other formats/
15:08:48 <tinkster> +1
15:09:09 <manu1> PROPOSAL: Provide language in the RDFa Core spec to allow non-RDFa, and non-RDF serializations for RDFa Profile documents.
15:09:09 <ShaneM> Shane: +1
15:09:10 <tinkster> (and +1 to ShaneM's proposed wording)
15:09:11 <Steven> +1
15:09:12 <Knud> +1
15:09:29 <tinkster> +1
15:09:48 <tinkster> +1's for everyone!
15:09:53 <ShaneM> "When an RDFa Profile is defined using an approved RDFa Host Language, the processing rules are:"
15:09:55 <nathan> +1 (for well-defined other types, for now that's only other rdf serializations)
15:10:44 <manu1> +1
15:11:00 <tinkster> s/an approved RDFa Host Language/an approved RDFa Host Language, or any other RDF serialisation/
15:11:16 <Knud> "When an RDFa Profile is defined using an approved RDFa Host Language - or any other RDF serialization - the processing rules are:"
15:11:22 <tinkster> sorry, I don't know if that altered the logs - didn't mean to - force of habit.
15:11:51 <ShaneM> markbirbeck: there are potentially issues with this.
15:11:59 <ShaneM> manu1: are these editorial or substantive?
15:12:02 <tinkster> what i mean is that we don't want people saying, "I'm using Turtle, so I'll come up with a whole new vocab".
15:12:14 <ShaneM> markbirbeck: They are probably editorial.
15:12:49 <ShaneM> ShaneM: I agree with tinkster.  if you are using an RDF serialisation... you need to use these predicates.
15:13:08 <ShaneM> markbirbeck: (says same thing ShaneM typed ;-)
15:13:51 <ShaneM> markbirbeck: don't worry about word smithing now - Shane will get it right.
15:13:55 <ShaneM> (manu word smiths anyway)
15:13:58 <manu1> PROPOSAL: Provide language in the RDFa Core spec to allow non-RDFa, and non-RDF serializations for RDFa Profile documents. If implementers use RDF to express prefix and term mappings, they MUST use the vocabulary defined in the RDFa Core specification.
15:14:17 <ShaneM> Shane: +1
15:14:18 <manu1> +1
15:14:21 <Knud> +1
15:14:23 <markbirbeck> +1
15:14:32 <tinkster> +1
15:14:38 <Steven> +1
15:14:42 <nathan> +1 (well defined non-RDF though)
15:14:50 <manu1> RESOLVED: Provide language in the RDFa Core spec to allow non-RDFa, and non-RDF serializations for RDFa Profile documents. If implementers use RDF to express prefix and term mappings, they MUST use the vocabulary defined in the RDFa Core specification.
15:15:12 <Zakim> -nathan
15:15:35 <manu1> Topic: Discussing any open objections
15:15:47 <tinkster> maybe link to a wiki page from the spec where people can document non-RDF implementations for easy discovery. can we link to wiki pages in a rec track document?
15:15:51 <manu1> http://lists.w3.org/Archives/Public/public-rdfa-wg/2010Oct/0194.html
15:16:18 <ShaneM> yes tinkster - we can include a non-normative reference to anything
15:16:55 <ShaneM> manu1: W.r.t. TERM processing - do a case sensitive check first... if that fails, then do a case insensitive match.  Any objections?
15:17:00 <Knud> no
15:17:01 <ShaneM> markbirbeck: no - its a good idea.
15:17:06 <ShaneM> its fine
15:17:13 <tinkster> +1
15:17:21 <manu1> http://lists.w3.org/Archives/Public/public-rdfa-wg/2010Oct/0231.html
15:17:26 <tinkster> I've already released a version of my parser that supports it.
15:19:16 <ShaneM> manu1: is the proposed text from Ivan okay?
15:19:42 <ShaneM> markbirbeck: its not as clear as I would like... some of the prior text that was proposed was just wrong.  The new proposal is at least not wrong.
15:19:49 <ShaneM> manu1: any strong objections?
15:19:56 <ShaneM> I SOOOO don't care
15:20:22 <ShaneM> markbirbeck: ShaneM pointed out that this should really be in the RDFa API document.
15:20:34 <ShaneM> manu1: are you saying you want to see a proposal to include that information in the RDFa API spec?
15:20:54 <ShaneM> markbirbeck: ...  only if it wouldn't hold anything up.
15:21:32 <ShaneM> manu1: I just don't think this is an issue that people feel very strongly about.  Moreover, we have not received any complaints about it from the public.
15:21:38 <tinkster> I think we *should* include an example that has changed bnode identifiers, but i don't think this debate is worth the time we've spent on it.
15:21:53 <ShaneM> ... if this is text that Ivan is fine with, then we might as well go ahead.
15:22:05 <manu1> PROPOSAL: Accept Ivan's edited changes to Mark's proposal: http://lists.w3.org/Archives/Public/public-rdfa-wg/2010Oct/0231.html
15:22:22 <manu1> PROPOSAL: Close ISSUE-37 - accept Ivan's edited changes to Mark's proposal: http://lists.w3.org/Archives/Public/public-rdfa-wg/2010Oct/0231.html
15:22:28 <manu1> +1
15:22:37 <Knud> +1
15:22:38 <markbirbeck> +0
15:22:41 <markbirbeck> :)
15:22:44 <ShaneM> Shane: +0
15:23:09 <ShaneM> I note that this text fails the grandmother text.
15:23:09 <tinkster> +1
15:23:11 <Steven> +1
15:23:16 <ShaneM> I mean test.
15:23:30 <manu1> RESOLVED: Close ISSUE-37 - accept Ivan's edited changes to Mark's proposal: http://lists.w3.org/Archives/Public/public-rdfa-wg/2010Oct/0231.html
15:23:44 <ShaneM> TOPIC: Can we take RDFa Core 1.1 to last call?
15:24:09 <tinkster> i still have all these mostly editorial issues - http://lists.w3.org/Archives/Public/public-rdfa-wg/2010Oct/0215.html
15:24:51 <tinkster> 8.3.1.3 seems pretty important.
15:25:01 <tinkster> it's more than editorial i think.
15:25:41 <ShaneM> all of tinkster comments are correct and I will make those changes.
15:26:24 <tinkster> ok, then i'm happy to go to last call then.
15:26:59 <ShaneM> I do have a question tinkster - why /resource/ instead of /page/ ?  /resource redirects to /page 
15:28:16 <ShaneM> never mind - I changed it back
15:28:44 <tinkster> /resource/Albert_Einstein identiifies a person, who was born in the 19th century. /page/Albert_Einstein identifies a page that was created in the 21st century.
15:29:03 <markbirbeck> :)
15:29:14 <tinkster> the 303 redirect from a URI identifying a "thing" to a URI describing the thing is a common linked data pattern.
15:29:18 <manu1> PROPOSAL: RDFa Core 1.1 should proceed to Last Call with a publication date of October 26th 2010.
15:29:37 <ShaneM> Shane: +1
15:29:38 <manu1> +1
15:29:39 <Steven> +1
15:29:40 <Knud> +1
15:29:44 <tinkster> +1
15:29:45 <markbirbeck> +1
15:30:00 <manu1> Ivan did a +1 via e-mail
15:30:05 <manu1> Nathan: +1
15:30:19 <manu1> RESOLVED: RDFa Core 1.1 should proceed to Last Call with a publication date of October 26th 2010.
15:30:59 <markbirbeck> @tinkster: And with RDFa, /page/Albert_Einstein would identify a /graph/ that was created in the 21st Century, that's /about/ Albert Einstein. :)
15:31:50 <markbirbeck> Well done everyone!
15:32:17 <Zakim> -markbirbeck
15:32:18 <Zakim> -ShaneM
15:32:19 <Zakim> -Steven.a
15:32:23 <Zakim> -manu1
15:32:24 <Zakim> -Knud
15:32:24 <Zakim> SW_RDFa()10:00AM has ended
15:32:26 <Zakim> Attendees were ShaneM, +44.785.583.aaaa, tinkster, Steven.a, +35387689aabb, Knud, nathan, manu1, markbirbeck
15:37:02 <ShaneM> ShaneM has left #rdfa
# SPECIAL MARKER FOR CHATSYNC.  DO NOT EDIT THIS LINE OR BELOW.  SRCLINESUSED=00000329