14:53:26 RRSAgent has joined #rdfa 14:53:26 logging to http://www.w3.org/2011/02/10-rdfa-irc 14:53:28 RRSAgent, make logs world 14:53:28 Zakim has joined #rdfa 14:53:30 Zakim, this will be 7332 14:53:30 ok, trackbot; I see SW_RDFa()10:00AM scheduled to start in 7 minutes 14:53:31 Meeting: RDFa Working Group Teleconference 14:53:31 Date: 10 February 2011 14:54:14 Agenda: http://lists.w3.org/Archives/Public/public-rdfa-wg/2011Feb/0061.html 14:54:18 Chair: Manu 14:54:39 Present: Ivan, Nathan, Steven, Manu, Shane 14:59:46 ShaneM has joined #rdfa 15:00:22 zakim, dial ivan-voip 15:00:22 ok, ivan; the call is being made 15:00:24 SW_RDFa()10:00AM has now started 15:00:25 +Ivan 15:00:30 +??P18 15:00:47 +[IPcaller] 15:00:48 zakim, ??p18 is ShaneM 15:00:49 +ShaneM; got it 15:01:26 +??P27 15:01:28 Knud has joined #rdfa 15:01:32 +??P24 15:01:36 zakim, I am ??P24 15:01:36 +manu; got it 15:01:46 Zakim, I am ??P24 15:01:48 sorry, webr3, I do not see a party named '??P24' 15:01:49 Zakim, I am ??P27 15:01:50 +webr3; got it 15:01:58 zakim, mute me 15:02:02 webr3 should now be muted 15:02:20 zakim, unmute me 15:02:20 webr3 should no longer be muted 15:02:51 + +3539149aaaa 15:03:03 zakim, I am aaaa 15:03:03 +Knud; got it 15:03:45 zakim, dial steven-617 15:03:45 ok, Steven; the call is being made 15:03:46 +Steven 15:04:28 zakim, who is on the call? 15:04:28 On the phone I see Ivan, ShaneM, [IPcaller], webr3, manu, Knud, Steven 15:04:39 (ipcaller isn't there, that's me) 15:04:53 zakim, [IPcaller] is webr3 15:04:53 +webr3; got it 15:05:17 I /was/ ipcaller, i hung up, ipcaller name stayed.. 15:05:56 Topic: ISSUE-73 and ISSUE-78: RDFa Default Profile 15:05:57 Topic: ISSUE-73 and ISSUE-78: RDFa Default Profile 15:06:05 http://www.w3.org/2010/02/rdfa/track/issues/73 15:06:11 http://www.w3.org/2010/02/rdfa/track/issues/78 15:06:14 Proposal: http://lists.w3.org/Archives/Public/public-rdfa-wg/2011Feb/0099.html 15:07:28 ivan: choice for URIs for profiles is important, dated or not 15:07:43 ivan: I'll discuss with people in W3C about this 15:07:51 ACTION: Manu to contact SemWeb Coordination Group to discuss default RDFa Profile URLs 15:07:52 Created ACTION-59 - Contact SemWeb Coordination Group to discuss default RDFa Profile URLs [on Manu Sporny - due 2011-02-17]. 15:07:55 agenda+HCG 15:08:25 ... technical question: I read your mail as if we have a profile valid for RDFa Core, and a different one for HTML+RDFa etc, is that correct? 15:08:54 manu: I don't think we can have just one profile, for instance HTML will have custom terms 15:09:17 ivan: that creates some issues.. it means that any host language has the right to define a default profile 15:09:30 ... are there any restrictions on host languages? 15:10:10 ... or perhaps we say we have to default profiles, a core one for everyone, and some host languages can add a host specific one.. 15:11:20 ... not only W3C can control host languages, other standardization bodies could do other RDFa host languages, sem web activity lead can't constrain what they do 15:11:51 manu: host languages could override default profile.. 15:12:08 ivan: yes they could do that anyway by redeclaring all terms in default core profile 15:12:41 ivan: I am leaning that we have two, core profile for all RDF, and a language specific one 15:12:46 s/RDF/RDFa 15:13:10 Nathan: Core profile for all of RDF? Or core profile for all of RDFa? 15:14:06 ivan: we can't define for RDF, we are RDFa working group, RDF WG will need to decide that 15:14:20 Manu: Do we expect default profiles for RDF/XML or Turtle? 15:14:34 ivan: it may happen, it does not seem very likely for rdf/xml and turtle at least 15:15:04 The profile for RDFa - http://www.w3.org/2011/profiles/rdfa 15:15:15 The profile for (X)HTML+RDFa - http://www.w3.org/2011/profiles/htmlrdfa 15:15:25 Manu: we would be defining two profiles, RDFa default, profile for (X)HTML+RDFa 15:16:46 Ivan: Next Point, still related, we had a standing issue, if we do that, how do I know that I am managing XHTML+RDFa? (to get profile) 15:17:02 Manu: I was thinking we could trigger off (some element, etc) 15:17:37 Ivan: first question is, is this something we need in the document? 15:18:08 q+ to discuss announcement 15:18:10 Manu: yes.. 15:18:16 ack shanem 15:18:16 ShaneM, you wanted to discuss announcement 15:18:27 Ivan: i don't like this sniffing to much.. 15:18:56 Shane: I thought we debated and agreed 3/4 weeks ago that the only thing we'd put in the document was that we detect on media type 15:20:07 Manu: anybody disagree with triggering of media type to get the correct profile? 15:20:48 q+ 15:20:58 Manu: So we trigger off of "application/xhtml+xml" or "text/html" or "application/xml" (or whatever the proper mime-types are) 15:21:05 ack steven 15:21:17 general agreement heard (nobody disagrees) 15:21:59 Ivan: I am uneasy with the text: "Prefixes and terms MAY be /updated/ if the new meaning of the term or prefix is semantically backwards compatible with the previous term or prefix." 15:22:36 Manu: example for this is dublin core, dc11 vs dcterms - dc tried to make sure terms were "supported" in new vocab 15:22:51 .. you could change vocab uri and have same meaning 15:23:09 ivan: no that's wrong, the two are very different, from rdf point of view 15:23:53 manu: i said semantically because the meaning hasn't changed domain + range setting still means property means "title" 15:24:06 manu: how are they not the same? 15:24:29 ivan: because RDF and other tooling sees things differently, takign in to account these new statements 15:24:42 ivan: as a rule we should say, prefixes and terms should nto be changed 15:25:07 Why commit ourselves one way or the other? 15:25:33 shane: I don't know if I agree w/ ivan, let's consider og: (opengraph for a while...) [considers] 15:25:35 Only because we're trying to give guidance to vocabulary authors, Steven. 15:26:08 ... og may change data at their uri, updating it - if that's correct why isn't the other? 15:26:30 ivan: that's correct, this is a problem at sem web level and RDFa should not even attempt to solve 15:26:32 Steven, I don't think we're trying to commit ourselves - just give guidance? (but we may be accidentally committing ourselves) 15:27:12 ... what manu proposes is that the triples will be different (differen uris) 15:27:27 q+ to agre w/ ivan 15:28:00 ack webr3 15:28:00 webr3, you wanted to agre w/ ivan 15:28:30 q+ to discuss dating 15:28:40 q- 15:28:56 nathan: also people hard code against URIs, we can't have them changing 15:28:59 6. Vocabulary maintainers SHOULD include an 'Expires' header in the HTTP response when a profile is dereferenced via HTTP. RDFa processors MAY use this header to implement local caching of the profiles. 15:29:36 Nathan: We should also probably put "Last-Modified", etc. 15:30:12 Nathan: "E-tag" if possible, "Cache-Control"... 15:30:37 Ivan: Concerned that that's going to be difficult to implement - too complicated. 15:30:47 Nathan: The server should generate everything correctly. 15:31:08 Manu: probably want to write or point to some good guidance on caching 15:31:40 Ivan: yes everything is set automatically, but Expires needs set specifically normally 15:31:54 Ivan: last thing is dated vs non dated uris for profiles 15:32:28 q+ to discuss URI dating 15:32:32 q+ to disagree with ivan's URI propsoal 15:32:39 ... I want to suggest we have non dated URI and provide dated too so people can reference explicitly 15:33:03 ack manu 15:33:03 manu, you wanted to discuss URI dating 15:33:35 Manu: I'm fine with versioned URI, issue i have with unversioned is that we could never remove prefixes or terms from it 15:34:01 Nathan: We also have to keep /terms/ in mind. 15:34:13 ack shanem 15:34:15 ShaneM, you wanted to disagree with ivan's URI propsoal 15:34:44 Shane: I agree w/ you manu - we debated this the other day, it was a light discussion 15:35:14 ... if we have a /tr/ space URI then it means we can never remove a prefix 15:35:33 ivan: but that's what caching is for 15:35:42 What happens when somebody does this in 2011: profile="http://w3.org/profiles/htmlrdfa" 15:35:47 shane: but as soon as I update to the latest profile, every document stops working 15:36:24 http://w3.org/profiles/htmlrdfa 15:36:37 ivan: but the proposal of manu is to say that we will have a new dated profile where it's lost anyway 15:38:13 (scribe misses what manu says, he seems to be going against the idea of unversioned uris) 15:38:59 ivan: we removed any way to tell what version of RDFa is being used 15:39:00 Manu: I think that we need to either have a versioned or dated URI 15:39:30 ivan: maybe we need to have version in there again (?) 15:40:01 manu: we tell people not to use profiles if they want interop, if they do want to use a profile they should mention which profile specifically 15:40:31 ... and our fallback is, if they haven't done any of it, we'll use the latest default profile to try and get some triples out 15:40:59 ... so we have levels of protection 15:41:06 ivan: okay, i see what you mean... 15:41:39 ivan: I think it's fine then, let's just not use "2011" in the uri 15:41:55 What about http://w3.org/profiles/rdfa11 and http://w3.org/profiles/htmlrdfa11 ? 15:41:57 manu: k, mmm, k 15:42:03 What about http://w3.org/profiles/rdfa1.1 and http://w3.org/profiles/htmlrdfa1.1 ? 15:42:11 What about http://w3.org/profiles/rdfa1 and http://w3.org/profiles/htmlrdfa1 ? 15:42:16 nathan: remembers Ivan is goign to speak to w3c for guidance on this 15:43:03 manu: any other concerns? 15:43:55 Nathan: I think it's about as good and close as we can get - I don't like default profiles, but I don't think others agree with that viewpoint, so this is as good as we get. 15:44:24 ISSUE-73? 15:44:24 ISSUE-73 -- The RDFa WG needs to determine how each RDFa Profile document is managed -- open 15:44:24 http://www.w3.org/2010/02/rdfa/track/issues/73 15:44:36 manu: ivan you had 73? can you type up a response LC one? 15:45:00 ivan: it was raised by manu sporney, do we need to reply to him? 15:45:27 issue-78? 15:45:27 ISSUE-78 -- Should we have default prefixes and terms for host languages -- open 15:45:27 http://www.w3.org/2010/02/rdfa/track/issues/78 15:46:58 [general conversation about who LC replies to 78] 15:47:18 ACTION: Manu to write up RDFa Profile Management on RDFa Wiki 15:47:18 Created ACTION-60 - Write up RDFa Profile Management on RDFa Wiki [on Manu Sporny - due 2011-02-17]. 15:47:30 manu: I'll put a draft response on wiki, Ivan will clean up and respond properly 15:48:03 manu: I'll do the response to 73 15:48:06 ACTION: Manu to respond to ISSUE-73 15:48:06 Created ACTION-61 - Respond to ISSUE-73 [on Manu Sporny - due 2011-02-17]. 15:48:30 Ivan: next step will be at some point, what will be the initial content in these profiles? 15:48:57 manu: later, lets do it later please 15:49:29 shane: it's a last call issue to define these as part of the docs going out 15:50:20 ... we can't do it once it goes out, contents of default profile is tied to the spec, we need to get consensus, lc-wise, to it 15:50:31 q+ 15:50:39 manu: that effectively says we shouldn't change the default profile after it goes to rec.. 15:50:57 ack ivan 15:51:05 ... we could just define the minimum possible.. 15:51:33 ivan: i think we could do the following.. there is a core set of terms and prefixes we just need, we have to pop them in and collect them 15:51:48 ... what we should set up is the mechanism whereby the resolution will happen 15:54:00 ivan: let's only put in w3c well knows first, rdf: for example 15:54:20 ... then open up mechanism after rec to add new things 15:55:11 q+ to ask if any other spec references a "moving part" 15:55:22 ack webr3 15:55:22 webr3, you wanted to ask if any other spec references a "moving part" 15:56:09 nathan: does any other rec have this moving part to it? 15:56:27 ivan/steven: yes, plenty xml related to 15:56:52 manu: okay so we don't think this will hurt our LC 15:58:04 ... we need terms and prefixes to add 15:58:06 ACTION: Nathan to put together list of prefixes and terms for default profiles 15:58:06 Created ACTION-62 - Put together list of prefixes and terms for default profiles [on Nathan Rixham - due 2011-02-17]. 15:58:12 nathan: I'll do that 15:58:20 manu: top of the hour 15:59:31 ivan: how about edits? 15:59:41 shane: how should i do them, edit or propose edits? 15:59:54 manu: let's not get stuck behind the bike shed 16:00:20 ... my preference is just to edit the spec 16:00:30 shane: that's fine w/ me, that's my preference too 16:00:38 [general agreement] 16:00:43 -ShaneM 16:00:44 -Knud 16:00:44 -Steven 16:00:45 -manu 16:00:49 zakim, drop me 16:00:51 Knud has left #rdfa 16:00:52 Ivan is being disconnected 16:00:54 -Ivan 16:00:59 -webr3 16:01:08 meeting ended 16:01:15 tracker, make draft minutes 16:01:31 rrsagent, make draft minutes 16:01:31 I'm logging. I don't understand 'make draft minutes', webr3. Try /msg RRSAgent help 16:01:48 rrsagent, draft minutes 16:01:48 I have made the request to generate http://www.w3.org/2011/02/10-rdfa-minutes.html webr3 16:02:02 np 16:02:28 did you guys see the annevk post i pointed to at start of meeting? 16:02:57 yeah, I don't know what I think of it. 16:03:04 snap 16:03:13 although it's kinda fair points too 16:03:22 sure 16:03:30 and some of it sounds like whining. :P 16:03:51 I mean, all of us have to go through that stuff - people could say the same about WebSockets, HTML5, etc. 16:04:23 well that's what they get for not writing perfect specs first draft 16:04:30 ha 16:04:53 I didn't necessarily like the "we've been implementing /your/ vision and we haven't gotten anything for it." tone. 16:04:59 if you don't believe in the vision, do something else. 16:05:16 don't slave away working on someone else's vision when you don't believe in it. 16:05:44 yup, common vision is very important 16:05:51 and I think that he's not being completely honest with himself... he had a choice, and at some point thought that XML and XHTML was the right way to go. 16:05:57 disconnecting the lone participant, webr3.a, in SW_RDFa()10:00AM 16:06:00 SW_RDFa()10:00AM has ended 16:06:01 especialyl when trade offs are concerned - this is the 120 problem we have at the minute 16:06:01 Attendees were Ivan, ShaneM, manu, webr3, +3539149aaaa, Knud, Steven 16:06:14 ShaneM has left #rdfa 16:06:36 Yep - I'm fine with Microdata existing - just don't try and stop us from implementing our vision. 16:06:54 did you see: http://markmail.org/message/gzelah3xqxspuoy2 16:06:55 it may be wrong, but roadblocking someone who is trying to get something done is bad form 16:07:08 from '97, it covers all the tradeoffs made well i think 16:07:21 agree 16:07:39 That's not to say that people shouldn't criticize RDFa to the ends of the earth... but we do have a vision for this stuff, and some things have to be there in order for us to achieve that vision. 16:10:43 I think people think that we're single-minded in our approach to this stuff - and perhaps it comes off as that at times. 16:11:11 but the reason we keep giving folks the same answer over and over again is because we've put a great deal of thought and effort into the alternatives 16:11:24 yup, I've considered writing about it too recently 16:11:36 the whole space is far too complex i think 16:11:47 and, as you said with the default profiles, you don't want it but the rest of the group does and there has to be some consensus to move forward. 16:12:00 yup 16:12:26 it is - like I said, spec writing isn't about purity (imho) - it's about getting something out there that works for the largest community possible w/o over-extending yourself. 16:12:52 namespaces might have been an over-extension... but simultaneously, we use them all the time at our company. 16:13:01 (because the system we're building is non-trivial) 16:13:19 (and is meant to be distributed/extensible) 16:13:33 you use namespaces? or you use prefixes? the two are different 16:13:42 ooh, I thought you were inter-changing. 16:13:46 prefixes. 16:13:54 we don't use namespaces afaik 16:14:14 cool - would be nice to see xmlns out of core (imho) but i daren't raise it 16:14:15 I was saying that many people may not even need prefixes 16:14:28 we did as much as we could - near-deprecation. 16:14:35 and that opens the door to remove it completely in RDFa 2.0 16:14:49 (because we warned people not to use it) 16:15:58 why not just remove it? 16:16:15 html for example doesn't allow people to author some things, but requires processors to still detect it 16:16:17 objection by Steven - and it would also break backwards compatibility. 16:16:40 (it wouldn't if processors still had to use it, for xml types) 16:17:26 you can remove it from core and stick it in processing rules for xhtml+xml .. that it must be handled by processors 16:18:22 what happens to all the documents that are being published as "text/html" and using xmlns: ? 16:18:54 1: they're wrong, but 2: practically you put in a rules to rdfa core saying it should be picked up by processors, exactly where it is now 16:19:12 you just remove the @xmlns: definition from the spec so authors don't use it 16:19:53 remove: "xmlns:prefix (optional)" 16:20:28 keep 7.5 sequence step 4 16:20:36 ' some Host Languages may also permit the definition of mappings via @xmlns' 16:20:45 that way it's gone for authors, but bc is kept 16:21:45 hmm, but we effectively say that now, right? 16:21:59 actually, scratch that 16:22:03 we don't say that now 16:22:30 my concern is mostly with making sure all the RDFa 1.0 documents continue to work, regardless of their implementation language. 16:22:47 I think it would be very bad if RDFa 1.0 processor writers chose to not support xmlns: when doing a new implementation. 16:22:51 well processing rules will handle that.. we'd just stop new people using it.. 16:23:05 processing rules force it though :) it'd be handled 16:24:17 it's only mentioned in those two places, 1: it's defined, and 2: how to process 16:24:23 just remove (1) 16:27:39 hmm 16:27:49 I was pro-removal of xmlns: 16:28:11 (I was actually fighting against it from the very beginning, after coming into RDFa from the Microformats community) 16:28:55 but it's something that we've compromised on over the years and it's almost gone... if you want to try to push it a bit more, feel free, but I think that we'd have push-back. 16:28:58 but I could be wrong on that. 16:29:18 I think the main people you'd have to convince are Shane and Steven... don't know about Ivan... maybe Mark. 16:30:04 worth a try 16:30:06 btw.. 16:30:10 Ivan is here:-) 16:30:16 lol 16:30:18 and watching over your shoulder 16:30:34 do we even specify how namespaces should be concatenated in rdf? 16:30:47 I am not exactly sure how you would ensure backward compatibility 16:31:03 ivan, processing rules handle it 16:31:04 that is the only thing I care about vs. xmlns 16:31:13 please do 16:31:24 1: http://www.w3.org/TR/rdfa-core/#dfn-xmlns 16:31:51 2: http://www.w3.org/TR/rdfa-core/#sequence 16:31:59 see step 4 of 2 16:32:33 I'm proposing to remove (1) and keep (2), so we don't encourage authors to use xmlns at all, but we do get processors to handle xmlns which is out there (keepign bc) 16:32:45 hm 16:32:46 right, I get it 16:33:01 woops - sorry, thought you were talking to me :P 16:33:11 but then the xhtml+rdfa document should also say that that host language does allow xmlns 16:33:20 :-) 16:33:26 yes :) 16:33:44 but that'll be invisible to html+rdfa .. one less problem 16:34:16 so.... if I am a comformant processor, I see that my RDFa content is _not_ html or xhtml (or svg for backward compatibility) then I MUST ignore xmlns, right? 16:34:57 RDFa Core processing rules would state that xmlns: must be processed... 16:35:03 well, I am sorry, that is the way I would interpret this 16:35:09 nope - spec says: "Mappings are defined via @prefix. For backward compatibility, some Host Languages may also permit the definition of mappings via @xmlns. 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. Regardless of how the mapping is declared, the value to be mapped must be converted to lower case, and the URI is not processed in any way; in particular if it is a relative path 16:35:30 yes, so "e Host Languages may permit..." 16:35:44 think of the RDFa core doc as having two views (although it isn't split) authors, and processors - authors won't see mention of xmlns, processors will 16:35:45 but if we remove it from the xml host language, than this does not apply to that particular host language 16:35:55 hm. 16:36:28 it is less work for me not to touch it but I think a rigorous consequence of what you propose is to be strict about this and accept xmlns only for host languages that accept it 16:36:40 note that I am not against this, just exploring the consequences 16:37:10 xhtml+rdfa w/ text/html content-type? 16:37:17 we need to handle that.. 16:37:34 unless we had a trigger to detect it's xhtml not text/html that is 16:37:59 is there a rule to detect which host media type your on? 16:38:29 well... I check the media type in the HTTP return and the preferred prefixes 16:38:39 and I also check application/*+xml 16:38:55 if it is application/xhtml+xml or text/html, then I know what it is 16:39:00 does xhtml+rdfa delivered as "text/html" still process okay then? 16:39:07 yes 16:39:14 and can you tell that it is infact xhtml rather than html? 16:39:19 I do not care 16:39:38 I consider it as HTML5, run it through the HTML5 parser 16:39:58 in this sense, for me, only application/xhtml+xml is really XHTML 16:40:09 this is the HTML5 WG's view, isn't it? 16:40:24 god knows 16:40:43 for us though, I assume this processing rule is in step 4 takes care of xmlns regardless of host language or media type 16:40:54 so would need to stay (it makes processing easier all round) 16:40:57 I remember Hixie peeking into my code at some point (or was it Henri) and this was what he said... 16:41:12 you know what? with the current evolution of html5 this makes sense 16:41:38 after all, xhtml is (fortunately or unfortunately, I do not really care) a lost battle, we had better move on 16:42:01 yes but then the language must change 16:42:08 to? 16:42:17 ahh yes it must 16:42:54 For backward compatibility, @xmlns should also be processed, because some Host Languages may also permit its usage 16:42:57 or something like that 16:42:59 ''For backward compatibility, processors SHOULD recognize the definition of mappings via @xmlns.'' 16:43:04 yeah 16:43:05 yup, i agree 16:43:40 nathan, why don't you propose it on the mailing list, then you should duck because you will get reactions from Shane or Steven or Mark:-) 16:43:55 Manu was unhappy by the diminishing number of comments 16:43:56 :-) 16:44:02 will do :) and I'll semi duck, not shy about talking things out lol 16:49:29 can I make an LC comment? 16:49:45 (being a member of the group, but not here when that text was written) 16:50:02 Well... to be very strict about it, LC comments should be for outsiders 16:50:08 regardless of when you came:-) 16:50:27 In my view, just raise it is an issue that must be solved before LC anyway 16:50:28 but.... 16:50:40 Manu manages the policy, so you should ask him...:-) 16:50:59 ok :) I'll mail it to the list and manu can put it in an issue if he so feels 17:18:00 no point really mate, it's on list now w/ two +1's already 17:18:50 btw.. i wonder which bits of the CPs for 120 this invalidates.. 17:21:20 I'll +1 that as well 17:22:07 and Ivan - I'm very happy with a diminishing number of LC comments, yes :P 17:22:28 :-)