Warning:
This wiki has been archived and is now read-only.

Chatlog 2011-02-03

From RDFa Working Group Wiki
Jump to: navigation, search

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

14:49:30 <RRSAgent> RRSAgent has joined #rdfa
14:49:30 <RRSAgent> logging to http://www.w3.org/2011/02/03-rdfa-irc
14:49:32 <trackbot> RRSAgent, make logs world
14:49:32 <Zakim> Zakim has joined #rdfa
14:49:34 <trackbot> Zakim, this will be 7332
14:49:34 <Zakim> ok, trackbot; I see SW_RDFa()10:00AM scheduled to start in 11 minutes
14:49:35 <trackbot> Meeting: RDFa Working Group Teleconference
14:49:35 <trackbot> Date: 03 February 2011
14:50:42 <manu> Agenda: http://lists.w3.org/Archives/Public/public-rdfa-wg/2011Jan/0156.html
14:50:44 <manu> Chair: Manu
14:51:14 <manu> Present: Ivan, Manu, Toby, Nathan, Steven, ShaneM, Knud
14:58:26 <Zakim> SW_RDFa()10:00AM has now started
14:58:33 <Zakim> +tinkster
14:58:45 <tinkster> Zakim, mute me
14:58:45 <Zakim> sorry, tinkster, muting is not permitted when only one person is present
14:59:58 <Knud> Knud has joined #rdfa
15:00:18 <ShaneM> ShaneM has joined #rdfa
15:00:35 <Zakim> +??P14
15:00:39 <manu> zakim, I am ??P14
15:00:39 <Zakim> +manu; got it
15:00:40 <tinkster> Zakim, mute me
15:00:40 <Zakim> tinkster should now be muted
15:01:12 <Zakim> + +539149aaaa
15:01:23 <Zakim> +??P30
15:01:24 <Steven> zakim, dial steven-617
15:01:27 <Zakim> ok, Steven; the call is being made
15:01:30 <webr3> Zakim, i am ??
15:01:32 <Knud> zakim, I am aaaa
15:01:33 <Zakim> +Steven
15:01:37 <Zakim> +webr3; got it
15:01:43 <Zakim> +Knud; got it
15:03:04 <ivan> zakim, dial ivan-voip
15:03:04 <Zakim> ok, ivan; the call is being made
15:03:06 <Zakim> +Ivan
15:03:18 <manu> Found this interesting - Microdata authoring/usability testing consisted of 6 people (some of the major design decisions were made from that one study): http://blog.whatwg.org/usability-testing-html5
15:05:55 <Zakim> +??P22
15:06:04 <ShaneM> zakim, ??P22 is ShaneM
15:06:04 <Zakim> +ShaneM; got it
15:07:32 <Steven> Scribe: Steven
15:07:46 <manu> Topic: Quick updates
15:07:52 <tinkster> http://buzzword.org.uk/2011/Atom_plus_RDFa/spec.html
15:07:55 <Steven> Agenda: http://lists.w3.org/Archives/Public/public-rdfa-wg/2011Feb/0001.html
15:08:15 <Steven> Manu: Toby's working on an Atom+RDFa spec - just a heads-up
15:08:21 <Steven> ... we might want to publish as a note
15:08:37 <Steven> Ivan: I implement Toby's stuff already
15:08:39 <tinkster> Ivan++
15:09:04 <manu> Topic: ISSUE-69: xml and xmlns prefixes in Default RDFa Profile
15:09:22 <manu> http://www.w3.org/2010/02/rdfa/track/issues/69
15:09:54 <manu> Ivan's opinion: http://lists.w3.org/Archives/Public/public-rdfa-wg/2011Jan/0124.html
15:10:00 <Steven> Ivan: I already gave my opinion
15:10:09 <Steven> [Manu reads]
15:10:35 <Steven> Manu: You suggest xml and xmlns prefixes should be added
15:10:36 <manu>   xml   -> http://www.w3.org/XML/1998/namespace#
15:10:38 <manu>   xmlns -> http://www.w3.org/2000/xmlns/
15:10:54 <tinkster> hmm, xmlns:xmlns="..." is illegal to declare
15:11:01 <tinkster> additionally, prefix="xmlns: ..." is not.
15:11:01 <Steven> Shane: It is illegal to redeclare the xmlns prefix
15:11:16 <Steven> Ivan: I am in favour of declaring it
15:11:27 <Steven> ... or we could declare it as an error
15:11:37 <tinkster> also, xmlns:xml is legal to declare, provided you point it at the proper XML namespace.
15:11:48 <Steven> ... calling it an error makes sense
15:11:52 <ShaneM> Namespaces in XML says:  The prefix xml is by definition bound to the namespace name http://www.w3.org/XML/1998/namespace. It MAY, but need not, be declared, and  MUST NOT be  bound to any other namespace name.  Other prefixes MUST NOT be bound to this namespace name, and it MUST NOT be declared as the default namespace.    The prefix xmlns is used only to declare namespace bindings and is by definition bound to the namespace name http://www.w3.org/2000/xmlns/. It
15:12:12 <ivan> http://lists.w3.org/Archives/Public/public-rdfa-wg/2011Jan/0009.html
15:12:42 <Steven> Ivan: Declaring them as illegal as prefixes might be cleaner
15:12:54 <Steven> ... but it means an extra check
15:13:39 <tinkster> RDFa 1.0 test suite test 0142 does already test that RDFa processors make this extra check.
15:14:23 <manu> TC 0142 is not a valid test, Toby?
15:14:36 <Steven> SHane: The XML Spec says that xmlns must not be declared
15:14:50 <Steven> Ivan: This is for CURIE prefixes
15:15:00 <Steven> ... it's not an XML issue, if you declare xmlns:xmlns or xmlns:xml to something invalid - that's the XML processors job to catch that.
15:15:22 <Steven> ... the issue is what to do if I use them in a prefix attribute - in CURIEs.
15:15:45 <Steven> Manu: Let's just declare xml and xmlns
15:16:01 <Steven> ... in the default profile
15:16:01 <tinkster> http://rdfa.digitalbazaar.com/test-suite/test-cases/xhtml1/0142.xhtml 
15:16:26 <Steven> Manu: Any objections?
15:16:29 <Steven> [none]
15:16:32 <manu> PROPOSAL: The RDFa Core 1.1 Default Profile should declare the 'xml' and 'xmlns' prefixes.
15:16:34 <ShaneM> +1
15:16:41 <ivan> +1
15:16:42 <manu> +1
15:16:45 <Steven> +0
15:16:45 <tinkster> +1
15:16:48 <Knud> +1
15:16:49 <webr3> +0
15:17:13 <tinkster> (maybe +0... I don't especially care about this either way - just thought it needed discussing)
15:17:23 <manu> RESOLVED: The RDFa Core 1.1 Default Profile should declare the 'xml' and 'xmlns' prefixes.
15:17:31 <Steven> Steven: Don't feel strongly on this either way
15:17:37 <Steven> Nathan: Likewise
15:17:40 <manu> Topic: ISSUE-74: Host Language Conformance
15:17:45 <manu> http://www.w3.org/2010/02/rdfa/track/issues/74
15:18:01 <trackbot> ISSUE-74 -- Host Language Conformance -- open
15:18:01 <trackbot> http://www.w3.org/2010/02/rdfa/track/issues/74
15:18:07 <tinkster> Zakim, unmute me
15:18:07 <Zakim> tinkster should no longer be muted
15:19:48 <Steven> [Brief discussion on how to mark issues that have been handled and not yet closed]
15:20:58 <Steven> Toby: Where is the divide between Core and the host language?
15:21:37 <Steven> ... special handling of body and head, etc
15:22:13 <Steven> ... My suggestion is that the host can do what it wants
15:22:42 <Steven> ... if it wants to provide an automated way to create an RDFa friendly version
15:23:09 <ivan> q+
15:23:15 <manu> ack ivan
15:23:47 <Steven> Ivan: Core uses @href and @src as part of its processing, though these are HTML attributes
15:24:28 <manu> SVG uses xlink:href ?
15:24:30 <manu> http://www.w3.org/TR/SVG/linking.html#Links
15:24:31 <Steven> ... so the clean way in an ideal world is some sort of automatic means of specifying which attr represents what in the processing
15:24:35 <Steven> q+
15:25:06 <ShaneM> q+ to discuss href / src 
15:25:35 <Steven> Ivan: On the GRDDL thing, @profile is also used by GRDDL (and others)
15:26:26 <Steven> ... so there is a potential clash, which would make me uncomfortable about mentioning it explicitely
15:26:47 <manu> ack Steven
15:27:12 <manu> Steven: Allowing host languages to do special stuff means that we don't have generic RDFa processors anymore.
15:27:32 <manu> Ivan: That's what we already have, though, right? We have to do special things for XHTML and XML...
15:27:54 <manu> Steven: We can have one or two special cases, we don't want to allow everything to be a special case.
15:28:07 <manu> Ivan: HTML has historical baggage, and we could just say that.
15:28:29 <Steven> Toby: That's what I'm saying; quirks are hard to handle in a general-purpose system
15:28:31 <manu> Toby: The more special cases a host language puts in, the less likely a generic RDFa processor is going to work.
15:29:48 <Steven> Manu: On the other hand, if host-langauges use special stuff they are less likely to be used since they won't work with generic systems
15:29:58 <tinkster> http://lists.w3.org/Archives/Public/public-rdfa-wg/2011Jan/0141.html
15:30:05 <manu> ack ShaneM
15:30:05 <Zakim> ShaneM, you wanted to discuss href / src
15:30:09 <Steven> q?
15:30:56 <Steven> Shane: I appreciate the concern, and we say that @href and @src are optional, and mention them explicitely in core as being optional
15:30:57 <ShaneM> http://www.w3.org/2010/02/rdfa/sources/rdfa-core/Overview-src.html#s_syntax
15:31:24 <Steven> Ivan: So if I have a host lang with @href and @src, then the relecant host-lang spec must say that they use @href?
15:32:30 <Steven> Manu: I would say just process @src and @href
15:32:38 <Steven> Ivan: But what does the spec say?
15:33:10 <Steven> Shane: I'm not sure if I agree with you Manu, we don't know what those attributes mean in another host language
15:33:21 <Steven> Ivan: We define it!
15:34:10 <manu> q+ to ask what other languages include href/src in a different way?
15:34:40 <Steven> Steven: I'm with Shane on this
15:34:53 <Steven> Ivan: But the spec says otherwise
15:34:58 <webr3> but href="lksdf lskdfj lskdjf lsd fj" could be valid for some +xml type, what happens when RDFa processor finds this?
15:35:01 <Steven> Shane: Only for host languages that support them
15:35:12 <tinkster> Zakim, mute me
15:35:12 <Zakim> tinkster should now be muted
15:35:19 <Steven> Shane: Section 7.5
15:35:38 <ShaneM> This specification defines processing rules for optional    attributes that may not be present in all Host Languages (e.g., @href).   If these attributes are not supported in   the Host Language, then the corresponding processing rules   are not relevant for that language.
15:35:57 <Steven> q+
15:36:27 <webr3> q+ to say not only must it be defined, but it must be defined in a compatible way
15:36:31 <tinkster> Atom has @src (or maybe @source?)
15:36:43 <Steven> Ivan: Atom has href, so a generic processor has to decide whether to handle href or not
15:37:07 <Steven> ManU: I agree in the sense that I think that the design is pure, however
15:37:31 <ShaneM> q+ to argue with manu
15:37:31 <Steven> ... ... I know of no other languages that use @href or @src otherwise
15:37:32 <tinkster> Yes, Atom has <content src> - roughly equivalent to <iframe src> in HTML.
15:38:07 <Steven> Ivan: I agree with href, but src? Not so sure.
15:38:25 <tinkster> <iframe src> can have children.
15:39:07 <Steven> Shane: In a generic XML grammar, I have crafted the choice of names. Who knows what I mean by @src.
15:39:15 <ShaneM> q- ShaneM
15:39:39 <manu> ack manu
15:39:39 <Zakim> manu, you wanted to ask what other languages include href/src in a different way?
15:39:45 <manu> ack Steven
15:39:55 <manu> ack webr3
15:39:55 <Zakim> webr3, you wanted to say not only must it be defined, but it must be defined in a compatible way
15:39:56 <ivan> q+
15:40:00 <tinkster> I say, support @href and @src in generic XML. If the host language uses those attributes for some incompatible purpose then it can not become an RDFa host language.
15:40:05 <Steven> Manu: We can't depend on mime type or @version, so if we don't know it is an HTML doc, we will fall back to XML processing
15:40:34 <Steven> Nathan: We need to say something specific
15:40:53 <Steven> Manu: But what do you do when you don't know the type of doc?
15:41:05 <Steven> Shane: XML, that's what the doc says
15:41:13 <manu> q?
15:41:16 <manu> ack ivan
15:41:17 <Steven> ... excellent point
15:41:35 <webr3> * and @rel
15:41:50 <tinkster> (The same goes for other attributes too - @resource, @about, etc...)
15:42:38 <Steven> Ivan: When designing my XML language, I should design with care
15:42:43 <webr3> q+ to ask if these aren't namespaced in +xml langs?
15:42:54 <manu> ack webr3
15:42:54 <Zakim> webr3, you wanted to ask if these aren't namespaced in +xml langs?
15:43:09 <tinkster> no, they're not.
15:43:24 <Zakim> -tinkster
15:43:54 <Zakim> + +1.785.583.aabb
15:44:04 <tinkster> Zakim, aabb is me.
15:44:04 <Zakim> +tinkster; got it
15:44:05 <manu> Nathan: Are RDFa attributes in a namespace?
15:44:12 <ShaneM> we say: If the Host Language uses XML Namespaces [XML-NAMES], the attributes in this specification should be defined in 'no namespace'.  (e.g., when the attributes are used on elements in the Host Language's namespace, they can be used with no qualifying prefix:  <myml:myElement property="next">).
15:44:16 <manu> Manu: No they're not - they're in the null namespace.
15:44:18 <Steven> Steven: Yes according to XHTML+RDFa
15:44:38 <Steven> ... Modularization allows them to be namespaced
15:44:58 <tinkster> Unless an attribute has a colon in it, it's not namespaced.
15:45:02 <Steven> Shane: host language attributes are normally not namespaced
15:45:22 <Steven> Steven: But you are allowed to say xhtml:about
15:45:33 <tinkster> Colon-less elements can be in a namespace, if there's a default one defined. But that doesn't apply to attributes.
15:45:35 <ShaneM> steven - I don't think that XHTML+RDFa permits namespaced attributes.
15:45:57 <tinkster> q+ to talk about ODF
15:46:04 <manu> ack tinkster
15:46:04 <Zakim> tinkster, you wanted to talk about ODF
15:46:27 <Steven> Toby: I thought we had language that allows them to be namespaced
15:46:39 <manu> If the Host Language uses XML Namespaces [XML-NAMES], the attributes in this specification should be incorporated in the namespace of the Host Language.
15:46:46 <Steven> Steven: Isn't it an excellent solution to this problem?
15:48:19 <Steven> Manu: It could be an optional feature
15:48:53 <Steven> ... If we have this issue, we need to solve it
15:48:54 <tinkster> My processor allows a host language specification to put RDFa attributes into a namespace, but currently the only host language I use it for is ODF.
15:49:10 <Steven> Steven: There you go!
15:49:27 <Steven> ... ODF does namespace the attributes
15:50:09 <Steven> Ivan: My original proposal holds
15:50:21 <Steven> Manu: We need a future agenda item on namespacing attributes
15:50:59 <manu> ISSUE: Can RDFa attributes be namespaced?
15:51:00 <trackbot> Created ISSUE-82 - Can RDFa attributes be namespaced? ; please complete additional details at http://www.w3.org/2010/02/rdfa/track/issues/82/edit .
15:51:13 <ShaneM> FYI - this is the text that Steven is alluding to: Each of the attributes defined in an XHTML attribute collection is  available for use when their corresponding module is included in an  XHTML Host Language or an XHTML Integration Set. In such a situation, the attributes are available for use in the definition of  elements that are NOT in the XHTML namespace when they are referenced  using their namespace-qualified identifier (e.g.,  xhtml:class). The semantics o
15:51:41 <Steven> Manu: Back to Jeni's issue, Ivan is suggesting adding @src and @href to core
15:52:47 <Steven> Steven: This is exactly what the XML people were afraid of, HTML dirtying XML
15:53:15 <manu> q+ to discuss whether RDFa is a "dirty" language
15:53:29 <Steven> Shane: The point is that we should be aware of pushback from XML people
15:53:44 <Steven> Ivan: We do this holding our noses, it comes from historical baggage
15:53:51 <manu> ack manu
15:53:51 <Zakim> manu, you wanted to discuss whether RDFa is a "dirty" language
15:54:13 <tinkster> For anyone designing an XML language, who doesn't like @src and @href... don't make your XML language into an RDFa host language. Problem solved.
15:54:27 <Steven> Manu: We have made decisions that are not great for people who like pure languages
15:54:44 <Steven> ... this is another of those decisions
15:54:55 <Steven> ... it is the best compromise
15:55:13 <manu> PROPOSAL: Add @href and @src to RDFa Core.
15:55:15 <ivan> +1
15:55:18 <Steven> +0
15:55:19 <tinkster> +1
15:55:20 <manu> +1
15:55:26 <ShaneM> NOTE - They are already in core - we are removing their optionality.
15:55:28 <ShaneM> +0
15:55:35 <Knud> +1
15:55:55 <webr3> +0
15:56:09 <Steven> Nathan: Not sure. Need to think longer
15:56:09 <tinkster> I think a host language spec should still be able to make their use non-conformant. However, an RDFa processor encountering them should still use them.
15:56:33 <Steven> Manu: We will go through another last call; reraise then if you have an issue with it
15:56:37 <manu> RESOLVED: Add @href and @src to RDFa Core (we are removing their optionality).
15:56:47 <Steven> Shane: Please try to raise issues now, because we don't want a third last call!
15:57:53 <Zakim> -tinkster
15:58:00 <Zakim> -Knud
15:58:16 <Zakim> -Steven
15:58:18 <Zakim> -webr3
16:01:12 <manu> zakim, who is on the call?
16:01:19 <Zakim> On the phone I see manu, Ivan, ShaneM
16:05:23 <ivan> zakim, drop me
16:05:23 <Zakim> Ivan is being disconnected
16:05:24 <Zakim> -Ivan
16:05:26 <Zakim> -manu
16:05:30 <manu> zakim, room for 4
16:05:30 <Zakim> I don't understand 'room for 4', manu
16:05:36 <ShaneM> zakim, drop me
16:05:36 <Zakim> ShaneM is being disconnected
16:05:38 <Zakim> SW_RDFa()10:00AM has ended
16:05:39 <Zakim> Attendees were tinkster, manu, +539149aaaa, Steven, webr3, Knud, Ivan, ShaneM, +1.785.583.aabb
16:06:02 <ivan> zakim, dial ivan-voip
16:06:03 <Zakim> ok, ivan; the call is being made
16:06:06 <Zakim> Team_(rdfa)16:05Z has now started
16:06:06 <Zakim> +Ivan
16:06:19 <Zakim> +??P4
16:06:23 <manu> zakim, I am ??P4
16:06:23 <Zakim> +manu; got it
16:06:27 <Zakim> +??P13
16:06:34 <webr3> Zakim, i am ??P13
16:06:34 <Zakim> +webr3; got it
16:07:41 <manu> scribenick: Manu
16:09:08 <Zakim> +ShaneM
16:09:55 <manu> Topic: ISSUE-76: RDFa Profiles
16:10:00 <manu> http://www.w3.org/2010/02/rdfa/track/issues/76
16:11:05 <manu> webr3: We've already resolved the first of Jeni's issues
16:11:05 <webr3> http://lists.w3.org/Archives/Public/public-rdfa-wg/2011Jan/0143.html
16:12:35 <manu> Nathan: There are two issues
16:13:12 <manu> Nathan: What is the range of rdfa:prefix and rdfa:term?
16:13:19 <manu> Shane: What does that mean?
16:14:10 <manu> Ivan: In RDF, via OWL inferencing, having a range definition is helpful - but there really isn't a way to say that in a "hint"
16:14:40 <manu> Ivan: Maybe we should remove the range triples from the vocabulary definition.
16:14:52 <manu> Ivan: It doesn't have any effect on our implementations
16:16:14 <manu> ACTION: Ivan to remove the range specification from the vocabulary definition for RDFa Profiles.
16:16:14 <trackbot> Created ACTION-57 - Remove the range specification from the vocabulary definition for RDFa Profiles. [on Ivan Herman - due 2011-02-10].
16:17:19 <manu> Ivan: I generate the TURTLE file out of an RDFa file - so it included metadata about the onology, but having that as part of the REC appendix does more harm than good.
16:17:56 <manu> Nathan: Ok, second issue here - Jeni is asking about the link relations from HTML5 - if they're in the profile or not.
16:18:03 <webr3> -> http://lists.w3.org/Archives/Public/public-rdfa-wg/2011Jan/0143.html
16:19:13 <manu> Ivan: The default profile would include the rel-values defined by the HTML5 mechanism.
16:19:41 <manu> Ivan: There a bunch of prefixes and there are a bunch of terms - we take what XHTML already has plus the HTML5 rel-values registry.
16:19:54 <tinkster> We need to go to Rec before HTMLL5 does (est 2022)
16:20:14 <manu> Manu: Are we going to add the IETF link types registry.
16:20:32 <manu> Ivan: Yes, I think so.
16:21:01 <manu> Ivan: I think our response should be - to the best of our knowledge, the HTML WG has not decided how they're going to manage these rel values, not everybody is in favor of the wiki approach.
16:21:14 <manu> Nathan: Larry Masinter has an action to look at this
16:21:47 <manu> Ivan: I think that what we ought to say is that the default profile will have a policy for the default profile update - that policy will have to take into account whatever the HTML WG will use.
16:21:55 <manu> Manu: We also have to take into account what the IETF group decides.
16:22:27 <manu> Nathan: We can't put the values in the RDFa default profile - they have completely different semantic meanings.
16:22:37 <tinkster> IETF registry can change very rapidly. RDFa profile is supposed to be pretty stable.
16:23:23 <manu> Nathan: none of the HTML5 rels don't have any use in RDFa - they'll create incorrect triples because the semantic meaning is different.
16:23:43 <manu> Ivan: RDFa as it is defined today already generates triples for "stylesheet", and "next" and "previous".
16:23:48 <manu> Shane: But, they're also not wrong.
16:24:38 <manu> Manu: I don't hear a clear direction forward.
16:25:13 <manu> Nathan: HTML5 has very specific meanings for its rel-values... for example if you do rel="help" it is associated with the paragraph, not the document.
16:26:14 <manu> Nathan: It appears that this isn't a break... they've always been this way. They were not always defined as a relationship w/ the document.
16:26:56 <manu> Nathan: I thought that @rel was a relationship between the document and the href.
16:27:33 <manu> Nathan: but it's really a key-value pair, and you have to figure out what the subject is based on the rel-value.
16:28:23 <manu> Ivan: This says, none of the values in HTML5 should be included in the default profile.
16:29:06 <manu> Ivan: I see two consequences, if we decide to do it this way, one of the consequences is a backwards-compatibility issue. Those were defined by RDFa 1.0 to generate triples. If we don't do that, we're breaking backwards-compat - even if the breaking of the BC is harmless.
16:29:23 <manu> Ivan: There will be a non-empty intersection between rel-values in HTML5 and the default RDFa Profile.
16:29:26 <ShaneM> http://www.w3.org/TR/rdfa-syntax/#relValues
16:30:00 <manu> Ivan: The other consequence is the notion of a default vocabulary URI - because if we have a @rel value term that is not defined, we use the default vocabulary URI.
16:30:15 <manu> Ivan: A profile can set a default vocabulary, but we don't have a default vocabulary by default.
16:30:16 <tinkster> HTML5's rel=help breaks back-compat with HTML 4's rel=help.
16:30:37 <ShaneM> Our spec says, for example, help  Refers to a resource offering help (more information, links to other sources of information, etc.)
16:31:15 <manu> Nathan: There is another way to handle this, dont' know how it can be codified yet, but if all of the rels for the terms were associated with a blank node, we would be doing the correct thing.
16:32:28 <tinkster> I assert that if resource H offers help for paragraph P, and paragraph P is contained within document D, then it is also true that resource H offers help for document D. So our triple is still correct.
16:32:46 <manu> Manu: Well, those triples are more or less useless - because you just know the k-v pair exists in the document... not very helpful.
16:33:18 <tinkster> Besides which, the microdata spec includes a mapping of rel=help to RDF, and their mapping is identical to ours.
16:33:41 <webr3> tobyink, the trouble is, that you say it relatate to the URI of the document/representation whatever - but if a subject is already set, RDFa will relate it to that..
16:35:11 <manu> Ivan: Outside of RDFa usage, @rel values were used outside the header, right?
16:35:29 <manu> Nathan: People are increasingly using things like rel="homepage"
16:35:48 <tinkster> true, but (especially if they've used @about) in these cases it's likely that the author knows what they're doing, and the RDFa interpretation is probably correct.
16:36:06 <manu> Ivan: Then the only way forward is to cut the bridges, and if people want terms in RDFa, they must be in the default profile.
16:37:16 <manu> Ivan: We should maintain the terms that we created in the past, we do not consider HTML5 relations that do not make sense in RDFa (the ones where the subjects are not known or have a strange algorithm for discovering the subject)
16:37:45 <manu> Ivan: Don't see any other way out of this - any solution than that seems like a complicated hack.
16:39:50 <manu> Shane: If we have a default profile, and the default profile doesn't include a term like "coffeecup", it's not going to be in the default profile. If I do that in an XML+RDFa document, nothing is going to happen.
16:40:40 <manu> Ivan: But it goes a bit deeper than that - if I put that in an HTML5 document and use the default profile, that profile doesn't include "coffeecup" that term will not be resolved.
16:41:22 <ShaneM> http://www.w3.org/TR/rdfa-syntax/#relValues
16:41:24 <manu> Shane: Technically, we're inheriting everything in RDFa 1.0 (all the terms)
16:43:09 <manu> Ivan: Regardless of this issue, we need to have an XPointer-like policy to register terms and prefixes.
16:43:19 <webr3> JeniT adds: "Or will the profile for HTML5 set a default vocabulary and thus possibly interpret NMTOKENs that should be ignored as CURIEs?"
16:43:56 <manu> Ivan: If some of the HTML5 terms make sense, someone is going to have to go through the same mechanism (the XPointer mechanism) to register the rel values.
16:45:14 <manu> Shane: Does Microdata use @rel?
16:45:16 <manu> Ivan: No
16:45:23 <manu> Nathan: But, Microformats does
16:46:18 <manu> Nathan: Do we have a default vocabulary URI?
16:47:00 <tinkster> We don't have a default vocab URI. Adding one breaks microformats quite badly.
16:47:04 <manu> Manu: no, we don't
16:47:38 <manu> Nathan: Then how do we inherit RDFa 1.0's terms?
16:47:47 <manu> Ivan: In RDFa 1.0, they were a list of terms in the spec.
16:47:54 <manu> Ivan: In RDFa 1.1, they are in the default profile.
16:48:32 <manu> Nathan: If in RDFa 1.0 was it the string terms or the URI terms that we inherited?
16:48:55 <manu> Nathan: In RDFa 1.0 when a term is discovered, do we go from one string to a URI.
16:50:03 <manu> Ivan: They have to be the same triples, that's what the charter says.
16:56:27 <manu> ACTION: Ivan to raise backwards-compat issue related to HTML5 rel values with W3M.
16:56:27 <trackbot> Created ACTION-58 - Raise backwards-compat issue related to HTML5 rel values with W3M. [on Ivan Herman - due 2011-02-10].
16:56:46 <manu> Nathan: We don't want to keep backwards compat w/ an old bug...
16:57:04 <manu> Ivan: It's not a bug, I don't think that's right. HTML5 looked at the terms and changed the semantics.
16:58:08 <manu> Shane: We could examine all of these terms, but do we agree that some of them are still okay. Like rel="license", is that okay?
16:59:29 <ShaneM> http://wiki.creativecommons.org/RDFa
17:00:22 <manu> Ivan: I for one, would love to get rid of the stylesheet rel.
17:00:23 <manu>	Manu: How are we answering Jeni?
17:00:24 <manu>	Ivan: The terms that we use in RDFa default profile are not going to automatically be the ones that the HTML5 defines because of the differences in semantics. We are going to have to consider all terms that go into the registry (whether from IETF, HTML5, or other).
# SPECIAL MARKER FOR CHATSYNC.  DO NOT EDIT THIS LINE OR BELOW.  SRCLINESUSED=00000362