IRC log of rdfa on 2011-01-13

Timestamps are in UTC.

14:59:25 [RRSAgent]
RRSAgent has joined #rdfa
14:59:25 [RRSAgent]
logging to
14:59:28 [trackbot]
RRSAgent, make logs world
14:59:29 [Zakim]
Zakim has joined #rdfa
14:59:30 [trackbot]
Zakim, this will be 7332
14:59:31 [trackbot]
Meeting: RDFa Working Group Teleconference
14:59:31 [trackbot]
Date: 13 January 2011
14:59:39 [Zakim]
ok, trackbot; I see SW_RDFa()10:00AM scheduled to start in 1 minute
14:59:41 [manu]
14:59:46 [manu]
Chair: Manu
15:00:07 [manu]
Present: Benjamin, Ivan, Manu, MarkB, Nathan, ShaneM
15:00:47 [Zakim]
SW_RDFa()10:00AM has now started
15:00:54 [Zakim]
15:01:01 [webr3]
Zakim, I am ?
15:01:01 [Zakim]
+webr3; got it
15:01:09 [Zakim]
15:01:13 [ivan]
zakim, dial ivan-voip
15:01:13 [Zakim]
ok, ivan; the call is being made
15:01:15 [Zakim]
15:01:33 [webr3]
scribenick: Nathan
15:01:42 [Zakim]
15:01:52 [ShaneM]
ShaneM has joined #rdfa
15:02:26 [webr3]
15:03:22 [manu]
zakim, who is on the phone?
15:03:22 [Zakim]
On the phone I see webr3, manu, Ivan, Benjamin
15:03:54 [ShaneM]
where is sip access to zzakim?
15:04:08 [ShaneM]
'cause I can't get dialin to work today
15:04:51 [Zakim]
15:04:54 [ShaneM]
never mind...
15:05:09 [manu]
zakim, who is on the phone?
15:05:09 [Zakim]
On the phone I see webr3, manu, Ivan, Benjamin, ShaneM
15:05:34 [webr3]
manu: let's go ahead and start, any additions / changes to the agenda?
15:05:46 [manu]
Topic: ISSUE-60: XMLLiteral context preservation
15:05:55 [manu]
15:06:27 [webr3]
manu: there are a number of things we can do to address this, some complicated
15:07:00 [webr3]
... all we need to do is preserve values in xmlns: and in no particular order, is that correct?
15:07:04 [ShaneM]
The text currently reads:
15:07:04 [ShaneM]
In order to maintain maximum portability of this literal, any children of the current node that are elements must have the current in scope profiles, default vocabulary, prefix mappings, and XML namespace declarations (if any) declared on the serialized element using their respective attributes. Since the child element node could also declare new prefix mappings or XML namespaces, t
15:07:37 [webr3]
ivan: in my implementation, I can produce all the xml statements, are definitions from within a prefix allowed?
15:07:57 [webr3]
manu: some @prefix values may override xmlns values
15:08:27 [webr3]
ivan: its really quite simple because all of this goes in to a single table
15:08:47 [webr3]
ivan: if i forget about the xmlliteral then I can do that, perfectly valid and works
15:09:16 [webr3]
manu: they need to be kept seperate for case insensitive searching
15:09:41 [webr3]
shane: you can't put everything in lowercase
15:10:21 [webr3]
shane: lets focus, i think it makes the msot sense to tell people to maintain different tables, regardless - did we agree that we weren't going to do what is currently in the draft
15:10:55 [webr3]
manu: i thought we decided against the text in the draft
15:11:30 [webr3]
ivan: i believe the core of what i said is true, it forces me to keep things seperate that at some point are not seperated
15:12:25 [manu]
This is the issue: xmlns:FOObar vs xmlns:foobar
15:13:12 [manu]
prefix="FOObar: ..."
15:13:24 [webr3]
manu: we need to keep these seperate because prefixes defined by xmlns are case insensitive, prefixes in @prefix are case sensitive
15:13:40 [webr3]
shane: why? (are they case sensitive)
15:13:55 [manu]
15:14:10 [webr3]
shane: they should not be case sensitive in @prefix
15:14:12 [manu]
term: "agent" => ...
15:14:13 [webr3]
ivan: they should not be case sensitive in @prefix
15:14:42 [manu]
prefix="Agent: ... , agent: ..."
15:14:56 [webr3]
ivan: prefix and term are different
15:15:07 [webr3]
manu: there's another issue which means they are not so different
15:15:39 [manu]
Agent => Class, agent => property
15:15:55 [webr3]
ivan: term and prefixes are different
15:16:06 [webr3]
shane: prefixes are only prefixes if they are followed by a colon
15:16:29 [webr3]
manu: mark and I believe prefixes are valid without a colon, used as tokens
15:16:40 [manu]
prefix="Agent: ... , agent: ..."
15:16:53 [Steven]
Steven has joined #rdfa
15:17:02 [Steven]
zakim, dial steven-617
15:17:02 [Zakim]
ok, Steven; the call is being made
15:17:03 [Zakim]
15:17:07 [ShaneM]
The text current reads: Otherwise, if a CURIE consists of a non-empty prefix and reference, and if there is an in-scope mapping for prefix (when compared case-insensitively), then the URI is created by using that mapping, and concatenating it with the reference.
15:17:39 [webr3]
Present: +Steven
15:17:53 [Steven]
zakim, who is on the phone?
15:17:53 [Zakim]
On the phone I see webr3, manu, Ivan, Benjamin, ShaneM, Steven
15:18:02 [webr3]
ivan: I worry that we may over-complicate rdfa
15:18:20 [ShaneM]
(to be clear, the xmlns syntax is NOT case insensitive - stupid browser implementations are)
15:18:23 [webr3]
ivan: prefix and xmlns should behave the same
15:18:40 [manu]
prefix="Agent: ... , agEnT: ..."
15:19:01 [webr3]
ivan: yes case insensitive
15:19:30 [webr3]
shane: it leads to more room for error
15:19:36 [webr3]
general agreement
15:20:46 [webr3]
manu: would we then have to encode all @prefix and @xmlns in XMLLiterals
15:21:19 [webr3]
ivan: we should not go out of our way for an infrequently used feature
15:21:34 [webr3]
manu: google do this, it is quite common, 30k sites++
15:22:46 [webr3]
ivan: if we map prefixes on to xmlns in the literals then it will all work
15:22:51 [webr3]
manu: seems a little strange
15:23:05 [webr3]
shane: i thought you were arguing that we sould only put xmlns on xmlliterals
15:23:09 [webr3]
manu: true
15:23:20 [webr3]
shane: doesn't that conflict w/ drupal use case
15:23:42 [webr3]
manu: are we making a decision to not allow deep processing of XMLLiterals
15:24:02 [webr3]
correct: google reference above should be drupal
15:24:44 [webr3]
manu: we can say 1: the only things that get preserved are xmlns statements (are prefixes included)
15:25:12 [webr3]
manu: or 2: we do not support deep processing of xmlliteral (w/ terms, profiles etc too)
15:25:28 [Steven]
s/google do this/Drupal do this/
15:25:54 [Steven]
s/correct: 01google reference above should be drupal//
15:26:03 [Steven]
rrsagent, make minutes
15:26:03 [RRSAgent]
I have made the request to generate Steven
15:26:26 [webr3]
ivan: it complicates implementations in a way I'm not happy about, but..
15:26:45 [webr3]
manu: if we were to preserve everything it would complicate things even more
15:26:59 [webr3]
ivan: i can live with that (2)
15:27:15 [Steven]
s/correct: g01oogle reference above should be drupal//
15:27:17 [webr3]
ivan: xmlns are pushed out to XMLLiteral and nothing else
15:27:46 [webr3]
manu: does that include things defined in @prefix or not?
15:27:56 [webr3]
many: any objections?
15:28:20 [webr3]
s/many: any objections?/manu: any objections?
15:28:32 [webr3]
manu: let's push it out to the list rather than strawpoll
15:29:14 [webr3]
ivan: we have to answer Gregg Kellogg w/ proposal and ask if they are happy with the resolution, will be in tracker
15:29:22 [manu]
Topic: ISSUE-62: @prefix processing order
15:29:25 [webr3]
no objections heard
15:29:31 [manu]
15:29:46 [manu]
@prefix="a: http://a.b a: http://c.d"
15:29:48 [manu]
will end in a->http://c.d
15:30:19 [webr3]
manu: order of prefix evaluation?
15:31:02 [webr3]
shane: prefixes are ordered from left to right, in the sequence, section 7.5 ..
15:31:29 [webr3]
ivan: need to specify this, no preference for which order
15:32:27 [webr3]
ivan: problem I have is that we have decided that the processing order of @profile is specified, so @prefix should probably be defined too, and match @profile
15:33:34 [webr3]
shane: @profile is age old and should be defined as @profile always has been - prefix does not have to be the same
15:33:58 [webr3]
ivan: within the same specification, they should be ordered the same to save errors
15:34:03 [webr3]
manu: i agree
15:34:57 [webr3]
manu: seems like last defined should win in presendence ( @prefix="a: http://a.b a: http://c.d" )
15:35:28 [webr3]
manu: where does it say in html4 how @profile values are given presedence
15:35:42 [webr3]
shane: common usage.. comes from css? some comment?
15:35:52 [webr3]
ivan: i think it has something to do with css
15:36:02 [ShaneM]
html4 says: profile = uri [CT] This attribute specifies the location of one or more meta data profiles, separated by white space. For future extensions, user agents should consider the value to be a list even though this specification only considers the first URI to be significant. Profiles are discussed below in the section on meta data.
15:36:23 [webr3]
manu: people are used to last declared wins
15:36:29 [webr3]
ivan: i agree
15:37:25 [webr3]
manu: shall we propose both profile and prefix are declared left to right, and last declared wins.
15:37:36 [manu]
15:40:23 [webr3]
ivan: it's more natural to say, processed from left to right, and has to be clearly documented
15:40:26 [ShaneM]
rdfa core says: If any conflict arises between two RDFa Profiles associated with URIs in the @profile value, the declaration from the RDFa Profile associated with the left-most URI takes precedence.
15:40:28 [manu]
Toby explained that the XMDP approach is to say that profiles appearing first in the list are /more significant/ than those coming later. That already points to a way of conceptualising this that is 'left-to-right'.
15:40:41 [Steven]
I propose we say "in document order" and not "left-to-right"
15:41:03 [webr3]
manu: i don't mind..
15:41:34 [webr3]
steven: "in document order" is what we say
15:41:54 [webr3]
shane: or "beginning to end" because languages have different directions
15:42:27 [webr3]
ivan: commenter is happy
15:43:05 [webr3]
all on call are happy with defining prefix and profile should follow in the same order, preference going to in document order
15:44:00 [webr3]
manu: no objections?
15:44:37 [webr3]
ivan: add a note to say right-to-left is more complicated than left-to-right
15:44:43 [manu]
Implementation experience states that processing right to left is far more complicated than left-to-right
15:44:49 [manu]
Topic: ISSUE-64: Add rel=describedby to the XHTML vocab
15:44:57 [manu]
15:45:21 [webr3]
manu: i think that's fine
15:45:56 [webr3]
ivan: there was a huge discussion about this on public lists, and sem web community "discovered" described by and that it should be used
15:46:19 [webr3]
ivan: we may have a seperate question about default profile - still undecided w/ an issue..
15:46:52 [webr3]
ivan: i think we decided we need a profile, not what it will contain
15:47:14 [webr3]
manu: yes issues are how do we decided what goes in, how it changes etc etc
15:47:31 [webr3]
ivan: I raised that because it would have to be in both profiles (xhtml and html)
15:48:14 [manu]
ZZZZ ISSUE-62 overturns decision made in ISSUE-23
15:48:32 [webr3]
manu: everyone okay with adding?
15:48:43 [webr3]
everyone: yes, good idea
15:48:49 [webr3]
manu: any objections
15:48:51 [webr3]
none heard..
15:48:51 [manu]
Topic: ISSUE-65: Michael Hausenblas' LC Comments
15:49:28 [webr3]
15:49:44 [manu]
15:50:05 [Zakim]
15:50:20 [Zakim]
15:50:20 [ShaneM]
suddenly it is very very quiet
15:50:36 [Steven]
I can hear you too
15:50:38 [Zakim]
15:50:53 [Zakim]
15:51:17 [webr3]
ivan: it looks like Michaels comments are editorial
15:51:40 [ivan]
15:52:20 [webr3]
ivan: Michael suggests a diagram, I've sketched one out
15:53:46 [webr3]
ivan: shane do you think this is something we should use, or will it over-complicate the document?
15:54:06 [webr3]
shane: still unsure.. let's discuss as it's editorial
15:54:12 [webr3]
ivan: agreement
15:54:25 [webr3]
ivan: can you all go through the diagram to double check
15:54:59 [webr3]
consensus: all editorial issues, make a decision about the diagram and add + respond to Michael
15:55:34 [ivan]
-> new charter
15:58:08 [manu]
Charter looks good AFAICT
15:58:32 [ivan]
zakim, drop me
15:58:36 [Zakim]
15:58:38 [Zakim]
15:58:40 [Zakim]
Ivan is being disconnected
15:58:42 [Zakim]
15:58:44 [Zakim]
15:58:46 [Zakim]
15:58:48 [Zakim]
15:58:50 [Zakim]
SW_RDFa()10:00AM has ended
15:58:57 [Zakim]
Attendees were webr3, manu, Ivan, Benjamin, ShaneM, Steven
15:59:46 [ivan]
16:00:01 [ivan]
I came up with the name, i would be happy to see alternatives
16:00:06 [manu]
(and specifically state that it deals w/ RDF in the charter)
16:00:39 [ivan]
structured data is so vague to me, we would get all the xml activity on our back
16:00:41 [webr3]
16:00:46 [ivan]
16:01:05 [webr3]
16:01:05 [ivan]
so putting a stake in the ground on RDF in the working group name is probably a good idea
16:01:05 [Benjamin]
that's good :)
16:02:26 [manu]
What about RDF API WG?
16:03:00 [ivan]
then the RDFa part goes down the drain
16:03:40 [manu]
True, but they'll be in LC in a few months, right?
16:03:55 [manu]
we can informally call ourselves the RDFa WG until that happens, then change to the new WG name?
16:03:58 [webr3]
WebRDF WG? (that'd go down well)
16:04:03 [manu]
16:04:06 [manu]
I do like that
16:04:27 [manu]
What about WebRDF WG, Ivan?
16:04:43 [manu]
(it's a bit redundant, but I don't care much about that)
16:06:47 [ivan]
WebRDF WG... yeah, maybe,
16:07:06 [ivan]
... doesn't that suggest too much?
16:07:09 [ivan]
... maybe not...
16:07:49 [ivan]
the RDF API WG is not really good for the lack of RDFa; yes, it is in LC in a few month, but the group has to go through the whole rec line
16:07:54 [ivan]
so that is not good
16:08:05 [ivan]
WebRDF WG... I will raise it with the team, too
16:09:02 [webr3]
general comment about sip: noted the new nexus phone from google has built in sip support
16:10:33 [ivan]
I have an iphone 4, and pretty happy with it...
16:10:34 [webr3]
ivan, webrdf may be a good name to save if linked data protocol ever gets standardized (which i personally think should happen asap)
16:11:01 [ivan]
the problem with webrdf is that it suggests RDF was not on the web until now...
16:11:25 [webr3]
does that matter?
16:11:37 [ivan]
well, it is all about imaging, isn't it?
16:11:55 [ivan]
anyway, I forwarded it to the team, it might be better than the current name anyway
16:12:05 [ivan]
so bye, see you around tomorrow
16:12:06 [webr3]
cool - cya & enjoy :)
16:12:16 [Benjamin]
16:20:20 [webr3]
rrsagent, make minutes
16:20:20 [RRSAgent]
I have made the request to generate webr3
16:20:58 [webr3]
Present: Nathan, Manu, Ivan, Benjamin, ShaneM, Steven
16:21:00 [webr3]
rrsagent, make minutes
16:21:00 [RRSAgent]
I have made the request to generate webr3
16:22:37 [webr3]
scribenick: webr3
16:22:38 [webr3]
rrsagent, make minutes
16:22:38 [RRSAgent]
I have made the request to generate webr3
16:23:00 [webr3]
rrsagent, make minutes
16:23:00 [RRSAgent]
I have made the request to generate webr3
16:24:20 [manu]
rrsagent, make logs public
16:24:31 [manu]
rrsagent, make minutes
16:24:31 [RRSAgent]
I have made the request to generate manu
16:25:31 [manu]
That's how you use the "old" RRSAgent system - have to make the logs public and then generate the minutes, then edit the HTML and post it to CVS - it's a bit unweildy compared to CommonScribe.
16:25:43 [manu]
16:26:15 [webr3]
cheers manu, there's a lot of trailing commentary on the minutes btw
16:26:29 [webr3]
manu, when do you want to discuss the APIs?
16:47:19 [ShaneM]
ShaneM has joined #rdfa
16:50:17 [ShaneM]
ShaneM has left #rdfa
18:06:13 [Zakim]
Zakim has left #rdfa