Chatlog 2011-02-14

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

15:00:00 <manu1> Chair: Manu
15:00:00 <manu1> Present: Ivan, ShaneM, Toby, Nathan, Manu
15:00:00 <manu1> scribenick: manu1
15:00:00 <Zakim> +[IPcaller]
15:00:00 <webr3> Zakim, I am IPcaller
15:00:00 <Zakim> ok, webr3, I now associate you with [IPcaller]
15:00:00 <ivan> zakim, dial ivan-voip
15:00:00 <Zakim> ok, ivan; the call is being made
15:00:00 <Zakim> +Ivan
15:00:00 <manu1> Agenda: http://lists.w3.org/Archives/Public/public-rdfa-wg/2011Feb/0120.html
15:00:00 <manu1> Topic: ISSUE-83: CURIEs must require colon
15:00:00 <manu1> http://www.w3.org/2010/02/rdfa/track/issues/83
15:00:00 <manu1> Manu: Nathan says that CURIEs should contain a ":"
15:00:00 <manu1> Manu: Shane says that we never wanted @vocab to affect CURIE processing in the way that it does right now - it's a spec bug.
15:00:00 <manu1> Shane: These issues are orthogonal.
15:00:00 <manu1> Nathan: I agree, they're orthogonal - and if we accept @vocab affecting only Term processing, the issue goes away.
15:00:00 <manu1> Ivan: The old CURIE spec allows a colon-less CURIE, right?
15:00:00 <manu1> Ivan: If I have property="foo" - is it a Term or a prefix w/o a colon?
15:00:00 <manu1> Shane: RDFa has never allowed a CURIE w/o a colon.
15:00:00 <manu1> Shane: The definition of CURIE permits a CURIE w/o a colon.
15:00:00 <manu1> Ivan: If RDFa has never allowed a CURIE w/o a colon, then we should enforce that.
15:00:00 <manu1> <div prefix="foafname: http://xmlns.com/foaf/0.1/name" property="foafname">Shane</div>
15:00:00 <tinkster> The <div> above is not the sort of CURIE without a colon that ISSUE-83 discusses.
15:00:00 <ShaneM> This is what Mark proposed in his 'tokens' approach
15:00:00 <tinkster> The CURIE without a colon is a CURIE with no prefix, no colon, but with a suffix.
15:00:00 <ShaneM> tinkster: yes
15:00:00 <tinkster> The definition of CURIE requires a colon whenever a prefix is given.
15:00:00 <ShaneM> tinkster: yes
15:00:00 <webr3> but not a prefix when a colon is given
15:00:00 <ShaneM> q+ to discuss the difference between a 'term' and a 'token'
15:00:00 <manu1> Ivan: What's the difference between a prefix-less CURIE and Term?
15:00:00 <manu1> Manu: The difference is artificial.
15:00:00 <webr3> iva, all terms are current valid CURIEs too, you just can't use them
15:00:00 <manu1> ack shaneM
15:00:00 <Zakim> ShaneM, you wanted to discuss the difference between a 'term' and a 'token'
15:00:00 <manu1> Shane: We debated this ad-nauseum - at the end of the day, we agreed to introduce terms as a way of having this abstraction.
15:00:00 <manu1> Shane: If you want to re-open the issue - we could do that.
15:00:00 <manu1> Ivan: Maybe the only thing we're missing here is that we don't have an attribute to define terms.
15:00:00 <manu1> Ivan: Maybe we should have @prefix and @term.
15:00:00 <manu1> Shane: You can use @vocab, but that only helps if all of your terms are in the same URL.
15:00:00 <webr3> q+ to say it wouldn't work
15:00:00 <manu1> ack webr3
15:00:00 <manu1> ack [IPcaller]
15:00:00 <Zakim> [IPcaller], you wanted to say it wouldn't work
15:00:00 <manu1> Nathan: It wouldn't necessarily work - you don't know if it's a relative IRI or a CURIE.
15:00:00 <ShaneM> about="lala"
15:00:00 <ShaneM> is that a 'curie that is only a prefix' or is it a 'relative uri' ?
15:00:00 <manu1> Shane: If you happened to have define a prefix "lala" then you're boned.
15:00:00 <manu1> Manu: Ok, then that is a huge problem.
15:00:00 <manu1> Ivan: In RDFa, we cannot have colon-less CURIEs.
15:00:00 <manu1> Shane: Yes, I believe that's correct.
15:00:00 <manu1> Shane: I referenced @vocab in the definition of CURIEs, there is this cross-pollination of something that shouldn't be there.
15:00:00 <manu1> Manu: Nathan, are you okay with this?
15:00:00 <manu1> Nathan: Yes, for the most part - there are other orthogonal issues, but we can discuss that later.
15:00:00 <ShaneM> ACTION: Clean up the cross-pollination of TERM, @vocab, and CURIEs
15:00:00 <trackbot> Sorry, couldn't find user - Clean
15:00:00 <ShaneM> ACTION: ShaneM Clean up the cross-pollination of TERM, @vocab, and CURIEs
15:00:00 <trackbot> Created ACTION-63 - Clean up the cross-pollination of TERM, @vocab, and CURIEs [on Shane McCarron - due 2011-02-21].
15:00:00 <manu1> PROPOSAL: Modify RDFa Core, @vocab MUST NOT affect CURIE processing - accept Shane's proposal for resolving this issue.
15:00:00 <webr3> +1
15:00:00 <manu1> +1
15:00:00 <ShaneM> +1
15:00:00 <ivan> +1
15:00:00 <tinkster> +1
15:00:00 <manu1> RESOLVED: Modify RDFa Core, @vocab MUST NOT affect CURIE processing - accept Shane's proposal for resolving this issue.
15:00:00 <manu1> Topic: ISSUE-82: The RDFa attribute namespace
15:00:00 <manu1> http://www.w3.org/2010/02/rdfa/track/issues/82
15:00:00 <manu1> Manu: So, how can we modularize RDFa 1.1?
15:00:00 <manu1> Ivan: How are these modifications going to be made?
15:00:00 <manu1> Manu: HTML4 DTD is a part of HTML+RDFa
15:00:00 <manu1> Shane: Anybody can create a modularization document for XHTML.
15:00:00 <manu1> Ivan: Then do we say that attributes are in the null namespace?
15:00:00 <tinkster> FWIW, my library supports RDFa attributes in arbitrary namespaces. The code that calls the library tells it which namespace to use - which can be null. But it has to pick a single namespace for a document - you can't mix and match.
15:00:00 <manu1> Shane: We can put stuff in the default namespace and the null namespace.
15:00:00 <manu1> Shane: Attributes are in no namespace - attributes can be namespaced, but generally they're not.
15:00:00 <manu1> Ivan: This tells me that we don't have an issue here - we do whatever RDFa 1.0 had done - it's not different from RDFa 1.0.
15:00:00 <tinkster> Colonless elements can be in a namespace (via xmlns="..."); Colonless attributes cannot.
15:00:00 <manu1> Manu: What about people that want to use @prefix in non-XHTML languages?
15:00:00 <manu1> Ivan: They're in the XHTML namespace.
15:00:00 <tinkster> Following on from my "FWIW"... of course the default namespace the library uses is null, except for OpenDocument where it's the XHTML namespace.
15:00:00 <manu1> Manu: xhv:prefix="foaf: http://xmlns.com/foaf/0.1/"
15:00:00 <manu1> Manu: That's what someone would do ?
15:00:00 <manu1> Ivan: Yes, that's one possibility. Or they could use it in no namespace at all.
15:00:00 <ivan> <lala about="http:///" > is fine
15:00:00 <tinkster> <entry xmlns="http://www.w3.org/2005/Atom" content="This content attribute is in no namespace, even though the entry element is." />
15:00:00 <manu1> Shane: Looking at our spec, there is language in some of the XHTML family specs that talks about this - I don't think RDFa Syntax has that language - it defines a module in Chapter 9, but it doesn't do it in the way that we normally define modules. The text isn't there that would lock it down.
15:00:00 <manu1> Shane: For example, in the @role attribute spec...
15:00:00 <ShaneM> http://www.w3.org/TR/role-attribute/#host-language-conformance
15:00:00 <manu1> Ivan: The only instance we know about, is how RDFa is used in ODF - it's in the XHTML namespace - they do it correctly.
15:00:00 <manu1> Shane: Should processors work the way that Toby's does? Yes - is that what most people are going to implement - probably not.
15:00:00 <manu1> Shane: Should we test for it?
15:00:00 <webr3> so we can do <elem about="foo" xhv:about="bar"> ?
15:00:00 <ShaneM> well.. no. XHTML says that is an error
15:00:00 <webr3> tfft
15:00:00 <ShaneM> XHTML M12N says you cannot combine the no namesapce and namespaced versions on the same element
15:00:00 <manu1> Manu: I don't think this should be a processor conformance requirement - it complicates processors too much, for very little benefit.
15:00:00 <manu1> Shane: We agreed to introduce XML+RDFa - are we specifying that via an XHTML-style module? Or are we saying that there are RDFa attributes that go in the null namespace?
15:00:00 <manu1> Ivan: The latter
15:00:00 <manu1> Manu: The latter
15:00:00 <tinkster> I think this should be the host language's business. It a host language wants to put it into http://foocorp.example/blah namespace, that's their funeral.
15:00:00 <tinkster> (which doesn't mean that we don't need to discuss it - after all, we're trying to take the XHTML+RDFa host language through last call as well!)
15:00:00 <manu1> Manu: In the RDFa Core spec, in the XML+RDFa section - we suggest that RDFa attributes are placed into the null namespace. If a host language wants to place them into a difference namespace, they can do so.
15:00:00 <ShaneM> For more on XHTML M12N attribute collections see http://www.w3.org/TR/xhtml-modularization/abstract_modules.html#s_commonatts
15:00:00 <manu1> PROPOSAL: The RDFa Core spec, in the XML+RDFa section should suggest that RDFa attributes are placed into the null namespace. Host Languages are allowed to place the RDFa attributes into a different namespace.
15:00:00 <ivan> +1
15:00:00 <manu1> +1
15:00:00 <ShaneM> +1
15:00:00 <webr3> +1
15:00:00 <tinkster> +1
15:00:00 <manu1> RESOLVED: The RDFa Core spec, in the XML+RDFa section should suggest that RDFa attributes are placed into the null namespace. Host Languages are allowed to place the RDFa attributes into a different namespace.
15:00:00 <manu1> Topic: ISSUE-84: Cool URIs and HTTPRange-14
15:00:00 <manu1> http://www.w3.org/2010/02/rdfa/track/issues/84
15:00:00 <manu1> Manu: WWW TAG wants us to warn people that there is no follow your nose story (yet) for fragment identifiers.
15:00:00 <manu1> Manu: There is no document that states how to interpret fragment identifiers via RFC3984 - no other document states this - they just want use to state that there is an issue
15:00:00 <manu1> Ivan: This whole issue is completely transparent to RDFa - RDFa is a serialization.
15:00:00 <manu1> Ivan: It's an important issue, but it doesn't have to do w/ the RDFa spec.
15:00:00 <manu1> Shane: We could add language in there to explain this.
15:00:00 <manu1> "Using #foo with RDFa is a great thing. However you should note that the media type registrations (RFC 3986) don't yet talk about this practice."
15:00:00 <manu1> "If you care about the possibility that the element and the linked data node might have different properties, you should use different fragment ids."
15:00:00 <manu1> <div id="currency" about="#currency">
15:00:00 <manu1> http://purl.org/money#currency
15:00:00 <manu1> <div id="ivan">This has nothing to do with Ivan</div>
15:00:00 <manu1> <div about="#ivan">This has something to do with Ivan</div>
15:00:00 <manu1> Manu: So, this is a best practice issue.
15:00:00 <manu1> Nathan: The @id is a locally scoped name - it's part of the representation.
15:00:00 <manu1> Nathan: The two @about and @id point to two different thing.
15:00:00 <manu1> Nathan: What the TAG is saying is that when you follow your nose, in some cases you get the element - in other cases you get a semantic object.
15:00:00 <manu1> What is this URL: http://example.org/foo#ivan ?
15:00:00 <webr3> with @about two strings are concatenated to create a single name / logical constant -> "http://example.org#ivan" an opaque id
15:00:00 <manu1> Ivan: It's a token - for a reasoning agent a URI is a token.
15:00:00 <tinkster> id="ivan" and about="#ivan" should never identify different things. (the technical possibility exists for them to do so, but it's just broken)
15:00:00 <webr3> with @id it refers to a name resolved within the scope of the representation, it's essentially _:ivan
15:00:00 <tinkster> webr3, no @id is globally addressable.
15:00:00 <manu1> Ivan: if I want to use something that is not an element, then I should use two different fragment identifiers.
15:00:00 <ShaneM> so you are saying about='#someToken' is effectively a named, externalized 'bnode' if there is no corresponding id='someToken' ?
15:00:00 <ivan> <div id="ivan">afasdfa</div> <div about="#ivan-lala"></div>
15:00:00 <manu1> Manu: Yes, we'd want to do that
15:00:00 <webr3> tinkster, only as part of the dereferencing process.. you have to split on #, dereference left part, then right part is a locally scoped identifier within the representation - the two are dif
15:00:00 <manu1> Ivan: I think this is for the cookbook and not for RDFa Core.
15:00:00 <manu1> Shane: If we can put this in the document in a short paragraph, let's do that.
15:00:00 <tinkster> Dereferencing has little to do with it.
15:00:00 <tinkster> I may not know what the URI <http://www.w3.org/2010/02/rdfa/sources/rdfa-api/#references> identifies until I've dereferenced it, but the representations of <http://www.w3.org/2010/02/rdfa/sources/rdfa-api/> should not define it inconsistently.
15:00:00 <ShaneM> ACTION: ShaneM Introduce a short paragraph about how frgids are not well defined by the corresponding RFCs and therefore why using them incorrect is potentially risky.
15:00:00 <trackbot> Created ACTION-64 - Introduce a short paragraph about how frgids are not well defined by the corresponding RFCs and therefore why using them incorrect is potentially risky. [on Shane McCarron - due 2011-02-21].
15:00:00 <manu1> Topic: Ensuring xmlns backwards-compatibility, but not mentioning xmlns
15:00:00 <manu1> http://lists.w3.org/Archives/Public/public-rdfa-wg/2011Feb/0104.html
15:00:00 <manu1> Manu: There seemed to be general agreement on the mailing list that we shouldn't specify xmlns: as one of the RDFa attributes, but should instead deprecate it. This is partly due to the HTML WG decision to not support decentralized extensibility, and also because we now have @prefix and that seems to sit with people better than xmlns:
15:00:00 <manu1> Manu: Shane, do you have any issues or concerns with this direction?
15:00:00 <manu1> Shane: Nope, sounds fine.
15:00:00 <manu1> Side-discussion about the political aspects of MUST vs. SHOULD vs. MAY - general agreement that the nuance will be lost on most people. Important thing is to support backwards compatibility, but show that RDFa is moving away from xmlns:
15:00:00 <ShaneM> ACTION: ShaneM to remove the definition of xmlns:prefix in section 5 and examples. Add prose in processing rules to ensure that processors are required to process xmlns:prefix for backward compatibility. Removed xmlns:prefix from all examples.
15:00:00 <trackbot> Created ACTION-65 - Remove the definition of xmlns:prefix in section 5 and examples. Add prose in processing rules to ensure that processors are required to process xmlns:prefix for backward compatibility. Removed xmlns:prefix from all examples. [on Shane McCarron - due 2011-02-21].
15:00:00 <ShaneM> For backward compatibility, some Host Languages MAY also permit the
15:00:00 <ShaneM> definition of mappings via <aref>xmlns</aref>. In this case, the value to be mapped is
15:00:00 <ShaneM> set by the XML namespace
15:00:00 <ShaneM> prefix, and the value to map is the value of the attribute — a URI.
15:00:00 <manu1> Manu: We should make it clear that we intend to remove xmlns: from RDFa and that authors shouldn't use it anymore.
15:00:00 <ShaneM> For backward compatibility, RDFa Processors MUST also also permit the definition of mappings via <aref>xmlns</aref>. In this case, the value to be mapped is set by the XML namespace prefix, and the value to map is the value of the attribute — a URI. (Note that prefix mapping via <aref>xmlns</aref> is deprecated, and may be removed in a future version of this specification.)
15:00:00 <manu1> Manu: +1 for something to that effect.
15:00:00 <manu1> Nathan: I think it should be "SHOULD"
15:00:00 <webr3> it wasn't made an ISSUE, i just proposed on list
15:00:00 <webr3> no issue number
15:00:00 <webr3> all text is in: http://lists.w3.org/Archives/Public/public-rdfa-wg/2011Feb/0104.html
15:00:00 <webr3> (exactly as discussed)
15:00:00 <manu1> PROPOSAL: Adopt the text that Shane specified above changing the MUST to a SHOULD: For backward compatibility, RDFa Processors SHOULD...
15:00:00 <manu1> +1
15:00:00 <ivan> +1
15:00:00 <webr3> +1 (and remove xmlns:prefix def text)
15:00:00 <ShaneM> +1
15:00:00 <manu1> RESOLVED: Adopt the text that Shane specified above changing the MUST to a SHOULD: For backward compatibility, RDFa Processors SHOULD...
15:00:00 <manu1> Topic: Supporting Terms in @prefix
15:00:00 <manu1> Manu: We already discussed this earlier in the call
15:00:00 <manu1> Manu: If we wanted to support prefix="foafname: http://xmlns.com/foaf/0.1/name". We can't do it because relative IRIs became ambiguous - are they a CURIE or are they a relative IRI? Having colon-less CURIEs is problematic because they're ambiguous vs. relative IRIs that may conflict w/ prefixes imported via @profile. 
15:00:00 <manu1> Ivan: What happens when you do this about="foo" and then you pull in a prefix via a @profile that defines "foo" as a prefix? Your markup all of a sudden starts having a different meaning which is hard to debug.
15:00:00 <manu1> General agreement that supporting tokens in @prefix is not possible to do in a way that is safe w/ the current design.
15:00:00 <manu1> Topic: RDFa Error Vocabulary
15:00:00 <manu1> Ivan: Do we want to integrate this into the document?
15:00:00 <manu1> Manu: I thought that we had agreed to do that?
15:00:00 <manu1> Shane: I thought so too.
15:00:00 <manu1> http://www.w3.org/2010/02/rdfa/wiki/Processor_Graph_Vocabulary
15:00:00 <manu1> Shane: That will go in an appendix?
15:00:00 <manu1> Ivan: Should it be in the rdfapg namespace? or just in the rdfa namespace?
15:00:00 <manu1> Manu: Same namespace.
15:00:00 <webr3> ok
15:00:00 <manu1> Nathan: From a design perspective, it might be nicer to have them in different namespaces - but I'm easy.
15:00:00 <manu1> General agreement that we should put the RDFa processor graph vocabulary terms in the RDFa namespace.
15:00:00 <manu1> Topic: ISSUE-77: Adding in extra blank node default subjects
15:00:00 <manu1> http://www.w3.org/2010/02/rdfa/track/issues/77
15:00:00 <manu1> Ivan: Don't really understand what he's asking for here?
15:00:00 <manu1> Ivan: Adding in extra blank node default subjects as a feature of RDF Profiles vocabularies, i.e. to make vocabularies like OGP produce valid triples. Note that in some instances of RDFa processing the profile is retrieved anyways, so might as well make it do very useful things.
15:00:00 <manu1> Manu: Are we saying that the profile will have processing rules in addition to prefixes/terms?
15:00:00 <manu1> Ivan: Anything in the header would have a subject as a blank node.
15:00:00 <manu1> Ivan: I think that this is not possible because there are other statements in the header that we generate triples for - this would be a backwards compatibility issue.
15:00:00 <ivan> apage satanas
15:00:00 <manu1> Manu: We had discussed this before - you'd need a generic plug-in architecture for the RDfa processing rules - we don't want to go down that road (it would take forever to get it right, if that was even possible)
15:00:00 <manu1> Manu: The result of that would be very difficult to understand for implementers - very meta.
15:00:00 <webr3> " we can't at the minute "
15:00:00 <manu1> Ivan: That's fine if we don't support this w/ me - it's asking for a /lot/ to happen.
15:00:00 <manu1> Ivan: We're shifting towards a default profile - I don't expect Facebook would create this document even if we had this functionality.
15:00:00 <ivan> ogp -> http://lalal.lal
15:00:00 <ivan> ogp -> http://lala.la#
15:00:00 <ivan> http://lala.la#e
15:00:00 <manu1> Ivan: If they add new properties, that's beyond our control.
15:00:00 <manu1> Shane: We were going to tell people that if they wanted to be in the default profile, they absolutely should not change the semantics of the vocabulary document over time.
15:00:00 <manu1> General agreement that attempting to do this correctly would become a specification and implementation nightmare.
15:00:00 <ivan> action: ivan to answer Harry on issue 77
15:00:00 <trackbot> Created ACTION-66 - Answer Harry on issue 77 [on Ivan Herman - due 2011-02-21].
15:00:00 <Zakim> -[IPcaller]
15:00:00 <ivan> zakim, drop me
15:00:00 <Zakim> Ivan is being disconnected
15:00:00 <Zakim> -ShaneM
15:00:00 <Zakim> -Ivan
15:00:00 <Zakim> -manu1
15:00:00 <Zakim> Team_(rdfa)16:00Z has ended
15:00:00 <Zakim> Attendees were +1.612.217.aaaa, ShaneM, manu1, [IPcaller], Ivan
# SPECIAL MARKER FOR CHATSYNC.  DO NOT EDIT THIS LINE OR BELOW.  SRCLINESUSED=00000207