IRC log of rdfa on 2011-12-08

Timestamps are in UTC.

15:02:28 [RRSAgent]
RRSAgent has joined #rdfa
15:02:28 [RRSAgent]
logging to http://www.w3.org/2011/12/08-rdfa-irc
15:02:30 [trackbot]
RRSAgent, make logs world
15:02:30 [Zakim]
Zakim has joined #rdfa
15:02:32 [trackbot]
Zakim, this will be 7332
15:02:32 [Zakim]
ok, trackbot; I see SW_RDFa()10:00AM scheduled to start 2 minutes ago
15:02:33 [trackbot]
Meeting: RDF Web Applications Working Group Teleconference
15:02:33 [trackbot]
Date: 08 December 2011
15:02:40 [manu1]
Agenda: http://lists.w3.org/Archives/Public/public-rdfa-wg/2011Dec/0025.html
15:03:38 [MacTed]
Zakim, this is 7332
15:03:38 [Zakim]
ok, MacTed; that matches SW_RDFa()10:00AM
15:03:39 [Zakim]
+??P17
15:03:41 [MacTed]
Zakim, who's here?
15:03:41 [Zakim]
On the phone I see ??P21, ??P18, OpenLink_Software, ??P17
15:03:42 [Zakim]
On IRC I see RRSAgent, niklasl, MacTed, bergie, danbri_, gkellogg, SebastianGermesin, trackbot, manu, manu1
15:03:43 [manu1]
zakim, I am ??P17
15:03:43 [Zakim]
+manu1; got it
15:03:51 [MacTed]
Zakim, OpenLink_Software is temporarily me
15:03:51 [Zakim]
+MacTed; got it
15:03:57 [MacTed]
Zakim, mute me
15:03:57 [Zakim]
MacTed should now be muted
15:04:01 [niklasl]
zakim, I am ??P18
15:04:01 [Zakim]
+niklasl; got it
15:04:05 [MacTed]
Zakim, unmute me
15:04:05 [Zakim]
MacTed should no longer be muted
15:04:26 [gkellogg]
zakim, who's here?
15:04:26 [Zakim]
On the phone I see ??P21, niklasl, MacTed, manu1
15:04:27 [Zakim]
On IRC I see RRSAgent, niklasl, MacTed, bergie, danbri_, gkellogg, SebastianGermesin, trackbot, manu, manu1
15:04:40 [gkellogg]
zakim, I am ??P21
15:04:40 [Zakim]
+gkellogg; got it
15:04:45 [MacTed]
Zakim, mute me
15:04:49 [Zakim]
MacTed should now be muted
15:09:33 [MacTed]
Zakim, unmute me
15:09:33 [Zakim]
MacTed should no longer be muted
15:09:48 [MacTed]
Zakim, mute me
15:09:48 [Zakim]
MacTed should now be muted
15:09:59 [manu1]
Scribe: manu1
15:10:17 [manu1]
Any updates/changes to Agenda? None.
15:10:20 [manu1]
Topic: ISSUE-114: HTML5 coerces @href/@src values to URLs instead of IRIs
15:10:29 [manu1]
http://www.w3.org/2010/02/rdfa/track/issues/114
15:11:36 [niklasl]
q+
15:11:43 [manu1]
manu1: We have two alternatives...
15:11:52 [manu1]
niklasl: Is it viable to de-percent encode?
15:12:29 [manu1]
manu1: I think so
15:12:46 [manu1]
niklasl: If somebody uses a percent-encoded URI in triples... how does that work out?
15:13:11 [manu1]
manu1: Our strategy to this point has been to just copy the data from the attribute w/o processing.
15:13:37 [ShaneM]
ShaneM has joined #rdfa
15:14:40 [gkellogg]
q+
15:14:46 [manu1]
ack niklasl
15:15:04 [Zakim]
+??P35
15:15:18 [ShaneM]
zakim, ??P35 is ShaneM
15:15:18 [Zakim]
+ShaneM; got it
15:15:31 [niklasl]
<http://example.org/å> = <http://example.org/%C3%A5>
15:15:34 [manu1]
manu1: We could keep doing that - and just warn people that they can't express all IRIs in HTML5 in @href and @src.
15:16:07 [manu1]
niklasl: Encountering both in data, expecting them both to be IRIs is a possibility, I think.
15:16:20 [manu1]
ack gkellogg
15:16:45 [manu1]
gkellogg: If we do percent decoding, we're the only ones that do - they do escape decoding of literals/URIs in order to remove the escapes... but they don't do the same for percent-encoding.
15:17:05 [manu1]
gkellogg: What is the least harm? Is it really likely that authors are going to try to represent two URIs differently?
15:17:16 [manu1]
gkellogg: percent-decoding might get to authors original intent...
15:17:34 [manu1]
gkellogg: Graph produced by RDFa may be different from the one generated from TURTLE... no silver bullet to this problem.
15:18:07 [manu1]
gkellogg: If @href and @src is not percent-decoded... we need to include @resource in RDFa Lite... otherwise, no way to express unicode object in HTML5.
15:18:37 [manu1]
manu1: Or, we could say that RDFa Lite cannot solve this particular use case.
15:18:56 [manu1]
gkellogg: I wonder if percent-decoding was considered in other groups.
15:20:36 [manu1]
manu1: We could provide both options in the RDFa Core spec... mark it up with a warning, then get feedback from HTML WG, WHAT WG, RDF WG, etc.
15:21:43 [gkellogg]
q+
15:23:23 [manu1]
PROPOSAL: In the HTML+RDFa spec, de-percent encode values retrieved from @href and @src in HTML5 before generating a triple based on those values. Include a warning that this feature is at risk during the Last Call.
15:23:30 [manu1]
ack gkellogg
15:24:20 [manu1]
gkellogg: I'm concerned about inter-operability... my library will not translate from IRI to URI... this concerns JavaScript implementations... anything using an infoset will get different results.
15:24:28 [ShaneM]
q+
15:24:28 [manu1]
gkellogg: We should note that that is a potential issue.
15:24:32 [manu1]
ack ShaneM
15:24:58 [manu1]
ShaneM: I appreciate what you're talking about wrt. percent-decoding - but what about URIs that have percents in them, happens all the time.
15:25:03 [niklasl]
q+
15:25:31 [manu1]
gkellogg: HTML5 spec is pretty specific, it has different rules for scheme, query, host portions - it's not simple.
15:25:40 [manu1]
ack niklasl
15:26:37 [manu1]
niklasl: Section 3.2 in the IRI spec might provide a means to lift items from URI to IRIs in a predictable manner. We may want to look at that more. If you do this in an HTML+RDFa parser, you have to check to make sure the input is UTF-8 decoded as well.
15:27:22 [manu1]
manu1: Do we want to implement this across everything that could contain an IRI?
15:27:29 [manu1]
ShaneM: absolutely.
15:28:27 [manu1]
manu1: If we do a percent-decoding across @href, @src, @about, @resource - will we get back what HTML5 expects as well?
15:28:31 [manu1]
gkellogg: I think so, yes.
15:29:31 [manu1]
gkellogg: For consistency's sake - it might be strange if you had @about not do percent-decoding, but did have percent-decoding in @href.
15:30:09 [manu1]
ShaneM: String comparisons wouldn't match between @about and @href, even if you dereference it, it refers to the same resource.
15:31:10 [ShaneM]
For instance if url was "//example.com/a^b☺c%FFd%z/?e", then the <path> component's substring would be "/a^b☺c%FFd%z/" and the two characters that would have to be escaped would be "^" and "☺". The result after this step was applied would therefore be that url now had the value "//example.com/a%5Eb%E2%98%BAc%FFd%z/?e".
15:31:46 [MacTed]
Zakim, unmute me
15:31:46 [Zakim]
MacTed should no longer be muted
15:32:10 [manu1]
MacTed: That's a bug in the HTML5 spec.
15:32:35 [manu1]
MacTed: It's presuming that the input wasn't percent-encoded.
15:33:08 [MacTed]
Zakim, mute me
15:33:08 [Zakim]
MacTed should now be muted
15:34:48 [ShaneM]
so we would transform http://www.example.com/foobar%2cblat to http://www.example.com/foobar,blat right?
15:35:09 [manu1]
manu1: Shane, yes - that is what the output should be.
15:35:37 [niklasl]
q+
15:35:50 [manu1]
ack niklasl
15:35:53 [niklasl]
<http://example.org/å> = <http://example.org/%C3%A5>
15:36:35 [manu1]
niklasl: I tried out the example above for both values, I get different IRIs internally from it.
15:37:02 [manu1]
niklasl: So, that's an argument against.
15:37:08 [ShaneM]
can we just defer to the RDF working group on this?
15:38:27 [manu1]
gkellogg: I don't think we want to make a spec change at this point.
15:39:07 [manu1]
gkellogg: I don't think anyone from the HTML WG have responded on this particular issue to Jeni's bug report on the problem. Issues should be raised on this in the HTML WG.
15:40:16 [manu1]
gkellogg: We should put a note in the HTML+RDFa spec notifying authors that this is the behavior for IRIs in @href, @src and @data.
15:41:38 [manu1]
PROPOSAL: Place a note in the HTML+RDFa specification notifying authors that IRIs placed into @href, @src and @data could be transformed if access via the DOM
15:42:18 [gkellogg]
+1
15:42:20 [manu1]
+1
15:42:26 [niklasl]
+1
15:42:32 [ShaneM]
+1
15:42:45 [MacTed]
+1
15:42:49 [manu1]
RESOLVED: Place a note in the HTML+RDFa specification notifying authors that IRIs placed into @href, @src and @data could be transformed if access via the DOM.
15:43:25 [manu1]
Topic: ISSUE-117: Do not automatically define @about on <body> and <head>
15:43:31 [manu1]
http://www.w3.org/2010/02/rdfa/track/issues/117
15:44:30 [manu1]
ShaneM: We do specify a default @about on the HTML element already - current subject is set to <base>
15:45:08 [manu1]
ShaneM: The implicit ones on HEAD and BODY is so that you could have a @typeof on the HEAD and BODY and have it refer to the document.
15:45:19 [ShaneM]
toby said: http://lists.w3.org/Archives/Public/public-rdfa-wg/2011Nov/0106.html
15:45:40 [manu1]
gkellogg: How common is it to have @typeof on HEAD and BODY without an @about or a @resource?
15:46:19 [niklasl]
q+
15:46:32 [manu1]
manu1: This issue isn't causing any damage right now, it also doesn't implement any new use cases.
15:46:32 [ShaneM]
mark makes a good argument here: http://lists.w3.org/Archives/Public/public-rdfa-wg/2011Nov/0151.html
15:46:53 [manu1]
niklasl: One possible issue is examples of this gives the impression that @typeof doesn't create bnodes.
15:46:57 [manu1]
ack niklasl
15:48:11 [ShaneM]
q+
15:49:21 [niklasl]
… <html about="/b"><h1 property="dc:title">B?</h1>
15:49:59 [ShaneM]
... <html about="/b"><head typeof="foaf:Document"> ...
15:50:42 [manu1]
gkellogg: This is an issue - how do you deal with documents that are malformed being processed via an XML-based processor that are HTML5 documents?
15:51:13 [niklasl]
q+
15:51:36 [manu1]
ack ShaneM
15:53:10 [MacTed]
inheritance preservation does feel like the right way to express this
15:53:14 [manu1]
ShaneM: I agree with Gregg - in the example above, we don't want to change the @subject for our author.
15:53:23 [manu1]
ack niklasl
15:54:14 [niklasl]
<body about="">
15:54:38 [ShaneM]
q+
15:54:43 [niklasl]
… <html about="/b"><body about=""><h1 property="dc:title">B?</h1>
15:55:06 [manu1]
niklasl: I agree - @property is applied to whatever the current subject is in the current rules... for @typeof
15:57:24 [ShaneM]
Original text: In section 7.5, processing step 5, if no IRI is provided by a resource attribute (e.g., @about, @href, @resource, or @src), then first check to see if the element is the head or body element. If it is, then act as if there is an empty @about present, and process it according to the rule for @about.
15:58:33 [ShaneM]
Revised text: In section 7.5, processing step 5, if no IRI is provided by a resource attribute (e.g., @about, @href, @resource, or @src), then first check to see if the element is the head or body element. If it is, then act as if new subject is set to parent object.
15:59:25 [ShaneM]
and: In section 7.5, processing step 6, if no IRI is provided by a resource attribute (e.g., @about, @href, @resource, or @src), then first check to see if the element is the head or body element. If it is, then act as if new subject is set to parent object.
15:59:52 [ShaneM]
I note that this has a (very minor) backward compatibility concern
16:00:31 [manu1]
PROPOSAL: Modify HTML+RDFa and XHTML+RDFa to modify processing steps #5 and #6 from assuming an empty @about value to assuming that new subject is set to the parent object.
16:00:49 [gkellogg]
+1
16:00:50 [manu1]
+1
16:00:52 [MacTed]
+1
16:00:53 [ShaneM]
+1
16:00:55 [niklasl]
+0.5
16:01:19 [manu1]
RESOLVED: Modify HTML+RDFa and XHTML+RDFa to modify processing steps #5 and #6 from assuming an empty @about value to assuming that new subject is set to the parent object.
16:03:30 [manu1]
Topic: ISSUE-122: @datatypeLibrary attribute
16:03:39 [manu1]
https://www.w3.org/2010/02/rdfa/track/issues/122
16:03:45 [manu1]
manu1: Anyone in support of this proposal?
16:04:20 [niklasl]
http://lists.w3.org/Archives/Public/public-rdfa-wg/2011Dec/0030.html
16:04:51 [Zakim]
-MacTed
16:05:02 [gkellogg]
From ivan: I am not convinced that the use cases warrant an additional level of complication in the RDFa definition. I would prefer not to take this.
16:05:19 [niklasl]
q+
16:05:38 [manu1]
manu1: I agree with that sentiment.
16:05:47 [manu1]
ack niklasl
16:05:57 [manu1]
niklasl: I agree - we pre-define xsd as a prefix, no need for this.
16:06:12 [manu1]
q?
16:06:22 [manu1]
ack shanem
16:06:24 [manu1]
ack niklasl
16:06:59 [ShaneM]
ack
16:07:23 [manu1]
manu1: I see no compelling use cases for this.
16:07:55 [manu1]
PROPOSAL: Do not support @datatypeLibrary proposal due to lack of compelling use cases.
16:07:59 [manu1]
+1
16:08:00 [niklasl]
+1
16:08:12 [manu1]
Ivan: +1
16:08:18 [gkellogg]
+1
16:08:21 [ShaneM]
+1
16:08:28 [manu1]
RESOLVED: Do not support @datatypeLibrary proposal due to lack of compelling use cases.
16:08:40 [manu1]
Topic: ISSUE-121: Use @id to set the subject in RDFa
16:08:49 [manu1]
http://www.w3.org/2010/02/rdfa/track/issues/121
16:08:55 [gkellogg]
q+
16:09:08 [manu1]
manu1: The issue with this suggestion is that we tread very heavily into HTTPRange-14 issues...
16:09:18 [niklasl]
q+
16:09:24 [manu1]
gkellogg: No compelling use case for it - very dangerous because it would break many documents that already use @id.
16:09:49 [manu1]
gkellogg: HTTPRange-14 is a huge issue as well... @id is in a different namespace as @about - I'm against including this feature in RDFa processing.
16:10:07 [niklasl]
… <div id="p_1" property="paragraf" resource="#p_1" typeof="Paragraf">
16:10:36 [manu1]
niklasl: I'm against it as well... it's always been something I would've liked, my primary use case for RDFa is for legal information, where we refer to document fragments more often than not.
16:11:11 [manu1]
niklasl: I have to use @resource on the same DIV... however, I'm still against doing what is proposed... very tricky to get what Sebastian is proposing right.
16:11:23 [manu1]
ack gkellogg
16:11:23 [ShaneM]
q+ just to mention the role attribute
16:11:25 [manu1]
ack niklasl
16:11:30 [manu1]
niklasl: Too complicated, don't support it.
16:11:31 [ShaneM]
ack just
16:11:31 [Zakim]
just, you wanted to mention the role attribute
16:12:24 [manu1]
ShaneM: I think it's a bad idea - @role attribute spec uses the value of @id as the subject... but you need both.
16:13:30 [manu1]
PROPOSAL: The @id attribute MUST NOT be used to identify a subject in RDFa.
16:13:33 [gkellogg]
+1
16:13:34 [manu1]
+1
16:13:43 [manu1]
+1 (from Ivan)
16:13:48 [niklasl]
+0.95
16:13:51 [ShaneM]
+1
16:14:05 [manu1]
RESOLVED: The @id attribute MUST NOT be used to identify a subject in RDFa.
16:14:12 [niklasl]
(.. the 0.05 is for my dream of a good working solution ;)
16:14:45 [manu1]
Topic: ISSUE-123: HTML Literals
16:14:53 [manu1]
https://www.w3.org/2010/02/rdfa/track/issues/123
16:15:18 [manu1]
gkellogg: The RDF WG has been looking at an HTML Literal - recent discussion on changes to XMLLiteral
16:15:41 [manu1]
gkellogg: My issue with XML Literals have always been the canonicalization rules - they're not valid to use in HTML.
16:16:05 [manu1]
gkellogg: Ivan's issue is that he doesn't know how an HTML Literal vs. an XML Literal would look...
16:16:43 [manu1]
gkellogg: The purpose of XMLLiteral support in RDFa is to capture markup, and not to look for document equivalence, then I think something like an HTML LIteral or relaxed requirements for canonicalization is more in keeping with RDFa usage patterns.
16:20:17 [manu1]
manu1: I wonder if there is any solution that we could create that would work both in XML-based and HTML-based parsers... I don't think there is.
16:20:28 [manu1]
gkellogg: Maybe the value should be the Infoset?
16:20:47 [niklasl]
q+
16:22:00 [manu1]
gkellogg: Exclusive canonicalization does more in terms of namespaces.... we may not want to do that sort of processing. wrt. an HTML document - there can be no namespaces... the effect may be equivalent. To say we coerce to Infoset, we are allowing the HTML parser to normalize the tagsoup and get a valid XHTML type representation of that content.
16:22:04 [manu1]
ack niklasl
16:22:45 [manu1]
niklasl: I think what we might be after is a way, given that we're in HTML, to use an equivalent to XHTML parsers - by using innerHTML property. I think that's spec'ed out in HTML5 spec.
16:23:41 [manu1]
gkellogg: If we just use innerHTML, the lexical representation is potentially tag soup. Presumably the value is an infoset.
16:25:11 [niklasl]
q+
16:25:50 [manu1]
ack niklasl
16:26:35 [manu1]
niklasl: Looking at the issue, this should be an HTML+RDFa issue... doesn't apply to RDFa Core - maybe we should wait for RDF WG to work through this issue.
16:27:52 [manu1]
Topic: Publication of RDFa Core 1.1
16:28:21 [manu1]
PROPOSAL: Publish an updated Working Draft of RDFa Core 1.1 on December 15th 2011.
16:28:24 [gkellogg]
+1
16:28:25 [manu1]
+1
16:28:27 [niklasl]
+1
16:29:35 [manu1]
We will also get +1s from the RDF Web Apps WG mailing list.
16:30:14 [ShaneM]
+1
16:30:16 [manu1]
RESOLVED: Publish an updated Working Draft of RDFa Core 1.1 on December 15th 2011.
16:30:31 [manu1]
Topic: Publication of XHTML+RDFa 1.1
16:30:47 [manu1]
PROPOSAL: Publish an updated Working Draft of XHTML+RDFa 1.1 on December 15th 2011.
16:30:49 [manu1]
+1
16:30:52 [niklasl]
+1
16:30:54 [gkellogg]
+1
16:30:59 [ShaneM]
+1
16:31:17 [manu1]
We will also get +1s from the RDF Web Apps WG mailing list.
16:31:20 [manu1]
RESOLVED: Publish an updated Working Draft of XHTML+RDFa 1.1 on December 15th 2011.
16:33:39 [Zakim]
-ShaneM
16:33:40 [Zakim]
-manu1
16:33:43 [Zakim]
-niklasl
16:33:44 [Zakim]
-gkellogg
16:33:44 [Zakim]
SW_RDFa()10:00AM has ended
16:33:45 [Zakim]
Attendees were manu1, MacTed, niklasl, gkellogg, ShaneM
16:38:56 [manu1]
trackbot, make logs public
16:38:56 [trackbot]
Sorry, manu1, I don't understand 'trackbot, make logs public'. Please refer to http://www.w3.org/2005/06/tracker/irc for help
16:39:04 [manu1]
RRSAgent, make logs public
16:50:05 [niklasl]
niklasl has left #rdfa
18:06:25 [MacTed]
RRSAgent, draft minutes
18:06:25 [RRSAgent]
I have made the request to generate http://www.w3.org/2011/12/08-rdfa-minutes.html MacTed
18:06:35 [MacTed]
RRSAgent, make logs public
18:06:38 [MacTed]
trackbot, end meeting
18:06:38 [trackbot]
Zakim, list attendees
18:06:38 [Zakim]
sorry, trackbot, I don't know what conference this is
18:06:39 [trackbot]
RRSAgent, please draft minutes
18:06:39 [RRSAgent]
I have made the request to generate http://www.w3.org/2011/12/08-rdfa-minutes.html trackbot
18:06:40 [trackbot]
RRSAgent, bye
18:06:40 [RRSAgent]
I see no action items