13:56:24 RRSAgent has joined #rdfa 13:56:24 logging to http://www.w3.org/2011/08/18-rdfa-irc 13:56:26 RRSAgent, make logs world 13:56:26 Zakim has joined #rdfa 13:56:28 Zakim, this will be 7332 13:56:28 ok, trackbot; I see SW_RDFa()10:00AM scheduled to start in 4 minutes 13:56:29 Meeting: RDF Web Applications Working Group Teleconference 13:56:29 Date: 18 August 2011 13:56:33 Agenda: http://lists.w3.org/Archives/Public/public-rdfa-wg/2011Aug/0034.html 13:56:38 Chair: Manu 13:57:23 SW_RDFa()10:00AM has now started 13:57:30 +??P2 13:57:48 zakim, I am ??P2 13:57:48 +lindstream; got it 13:58:44 +??P14 13:58:49 zakim, I am ??P14 13:58:49 +manu; got it 13:59:04 +??P8 13:59:18 zakim, I am ??P8 13:59:18 +gkellogg; got it 13:59:57 +OpenLink_Software 14:00:02 + +358.405.25aaaa 14:00:04 ShaneM has joined #rdfa 14:00:09 Zakim, OpenLink_Software is temporarily me 14:00:09 +MacTed; got it 14:00:12 Zakim, mute me 14:00:12 MacTed should now be muted 14:01:01 +??P29 14:01:05 zakim, I am ??P29 14:01:05 +ShaneM; got it 14:02:03 zakim, who is on the call? 14:02:05 On the phone I see lindstream, manu, gkellogg, MacTed (muted), +358.405.25aaaa, ShaneM 14:02:52 -ShaneM 14:03:49 +??P29 14:03:52 zakim, I am ??P29 14:03:52 +ShaneM; got it 14:04:12 scribenick: manu 14:04:43 Manu: Any other agenda items? Shane, your @profile issue? 14:04:48 Shane: Not yet, Ivan isn't here. 14:05:06 Gregg: Proxy vocab isn't going to relate to @profile... it's a separate issue. 14:05:20 Shane: Correct - @profile isn't the long pole in the tent anymore - Vocabulary Expansion is. 14:05:38 Topic: Vocabulary Expansion Update 14:05:52 Niklas: We haven't talked between us - haven't had time yet - began writing some of it. 14:06:09 Niklas: Looked at Ivan's text - administrative problem is access to CVS. 14:06:32 Niklas: I could write the text and and mail it to the list? 14:07:07 Manu: Gregg has CVS access and adding spec language - was going to start on it on my own... happy to take whatever Niklas has and work with that. Need some expository material, need that as well. Shane has the final say, of course. 14:07:26 s/was going/Gregg: I was going/ 14:08:34 Niklas: Could we hack on it on github? 14:08:52 Manu: No... just send the language to the mailing list, have Gregg integrate it. 14:09:08 http://www.w3.org/2010/02/rdfa/wiki/Main_Page 14:09:24 it's a wiki. it's in w3. it's a good place for collaborative text building... 14:09:39 Niklas: Some issues that we could add to the Agenda - if we have the time, I'd like to take up dereferencing IRI in @vocab directly. 14:10:45 scor has joined #rdfa 14:12:25 Topic: ISSUE-101: xsd:string coercion 14:12:31 The issue is here: http://www.w3.org/2010/02/rdfa/track/issues/101 14:12:43 Started in this thread: http://lists.w3.org/Archives/Public/public-rdfa-wg/2011Jun/0064.html 14:13:47 q+ 14:13:48 +scor 14:14:00 Manu: Should we change anything that is an xsd:string to a plain literal? 14:14:28 Gregg: My read of their finding was a bit different - abstract language uses xsd:string datatype for plain literals w/o a language. 14:14:37 http://lists.w3.org/Archives/Public/public-rdf-wg/2011Jul/0048.html 14:14:38 Gregg: Recent communication about how @lang might be handled. 14:14:46 http://lists.w3.org/Archives/Public/public-rdf-wg/2011Jul/0048.html 14:15:17 Gregg: One of the issues is how languages would be managed. I think we do want to follow their lead to not create any extra confusion. 14:15:27 Manu: Are you saying we need not do anything? 14:15:53 q+ 14:15:58 Gregg: No, we should express the abstract syntax - plain literals implicitly get a datatype string, when they're serialized, they're serialized w/o that datatype. 14:16:00 ack gkellogg 14:16:49 Niklas: After reading what Ivan wrote about this - I agree w/ Ivan - the problem is that today RDF libraries differentiate between datatype literals and plain literals w/o language. The new semantic interpretation would be that they are datatyped literals w/ xsd:string. 14:17:41 Niklas: An RDF spec would say that every time you generate a datatype w/ a plain string - old style processors would serialize these things w/ "xsd:string" at the end... and new ones would serialize as plain literals. 14:17:48 Niklas: Real problem is integration w/ RDF libraries. 14:17:55 ack lindstream 14:19:12 Manu explains his understanding of the issue. 14:20:02 q+ 14:20:16 Gregg: I'm trying to figure out how this could happen - if you have half-implemented systems... your parser is in the new mode (generating xsd:string) and your new serializer (generating plain literal) 14:20:42 Gregg: You could have a half-implemented issue here... 14:21:52 Niklas: Semantically, as the RDF WG is defining it - there is no longer a plain literals... if I send that data in-memory to another implementation... that could be an issue. We could create spec language for this - if you have an implementation, if you have something that differentiates between plain literals and xsd:string - do the new thing. 14:25:19 Gregg: The issue has to do w/ how you express the serialization. 14:25:55 Discussion about what RDFa Processors output - an RDF abstract model - or a serialized stream. 14:25:59 q+ 14:26:04 q+ 14:26:22 Shane: The issue is on the serialized output, not the model - because you don't really have access to that in many processors. 14:27:03 Niklas: There are two ways to express a string literals - when parsed these things are semantically equivalent. 14:27:31 Niklas: Let's say that semantically literals w/o datatype are actually literals w/ a datatype xsd:string. 14:28:06 Niklas; This difference can be expressed in RDFa - we can use an empty @lang attribute or a datatype xsd:string... the syntactic difference should be taken into account w/ RDFa libraries if they support this difference. 14:28:10 RDF WG: "foo" and corresponding forms in other concrete syntaxes are syntactic sugar for "foo"^^xsd:string. In general, both forms MAY be used and represent identical literals in the abstract syntax. 14:28:30 Niklas: If not, they should always be the literal w/ xsd:string - we can't force them to pick one or the other if they only support one thing. 14:29:18 Niklas: If they were to parse TURTLE, it wouldn't be wrong to preserve that in the model - it would be unnecessary semantically - nothing wrong w/ an RDFa parser to denote the syntactic differences. 14:29:34 Niklas: But there is no longer a semantic difference. 14:30:15 Manu: So, there is no change I need to make to my parser? 14:30:32 q+ to discuss Turtle spec language 14:30:36 ack lindstream 14:30:38 ack manu 14:31:33 Manu: So the problem is that two processors could generate different triples. 14:31:37 - +358.405.25aaaa 14:32:05 Niklas: Libraries/serializers are no longer separate - this may cause implementation issues going forward. 14:32:28 Niklas: That's the problem the RDF WG are facing... they can only preserve syntactic difference for libraries that maintain the difference in memory. 14:32:31 ack gkellogg 14:32:31 gkellogg, you wanted to discuss Turtle spec language 14:33:12 Literals have either a language suffix or a datatype IRI but not both. Languages are indicated by appending the simple literal with @ and the language tag. Datatype IRIs similarly append ^^ followed by any legal IRI form (full or prefixed) as described above to give the datatype IRI. Literals may be written without either a language tag or a datatype IRI as a shortcut for a literal with the type xsd:string. 14:33:15 Gregg: Looking at latest TURTLE spec, the way they approach that is that they say that literals may be written plain literals w/o datatype and language. 14:35:13 Manu: My concern is having RDFa Processors that generate different triples but are still conformant? 14:36:55 Niklas: I see the concern - the triples aren't different anymore at the serialization level. 14:37:13 Manu: I see this approach creating bugs... 14:38:21 Manu: Who would update their implementations based on this language? 14:38:24 Niklas: I would 14:38:30 Gregg: So would I 14:39:01 Niklas: I would expect that any sort of serialization diffs would disappear when SPARQL serializations changed. 14:39:22 Shane: I don't know if I'd make any changes. 14:40:22 Shane: Making us change plain literals to generate xsd:strings now is a backwards-incompatible change. 14:40:44 Gregg: it would be valid to take xsd:string tagged literals and represent them internally as plain literals. 14:41:29 Gregg: this is a phantom issue - abstract syntax is not directly visible in RDF API, is it? If we add a test to the test suite - one plain and one tagged w/ xsd:string - what would the test be for that? What would the SPARQL do? 14:42:12 Manu: Doesn't RDF API / RDF Interfaces operate on the abstract model. 14:44:39 Manu explains how this may impact librdfa implementation. 14:45:16 Gregg: Abstract for is that of a plain literal w/o datatype tag - still leads to backwards compatibility - xsd:string was never intended to be treated differently than plain literal. 14:45:51 Gregg: I think we should ask for some feedback from the WG. 14:46:11 ACTION: Gregg to contact Richard in RDF WG about xsd:string coercion. 14:46:12 Created ACTION-89 - Contact Richard in RDF WG about xsd:string coercion. [on Gregg Kellogg - due 2011-08-25]. 14:46:40 Topic: ISSUE-102: @prefix limit 14:46:50 Issue is here: http://www.w3.org/2010/02/rdfa/track/issues/102 14:48:10 Raised here http://lists.w3.org/Archives/Public/public-rdfa-wg/2011Jul/0044.html 14:49:54 q+ to propose we just close this issue. 14:50:32 Manu explain the issue 14:50:36 ack ShaneM 14:50:36 ShaneM, you wanted to propose we just close this issue. 14:51:22 Shane: We have to allow prefix everywhere - we should tell people about this issue - there is nothing we can solve here. We can put in warnings, best practices, but no normative spec change we can make. 14:52:18 q+ 14:52:28 Gregg: Yes, we should specify a best practice. 14:52:41 Niklas: yes, agree - close it - add best practices to the spec. 14:52:44 +1 best practices guidance, and warnings of what may happen if those are not followed... 14:52:50 ack lindstream 14:54:32 Niklas: The real problem might be the content type sniffing issue - RDFa in XHTML context - where encoding is done at top - UTF-8 by default. This hasn't been an issue for us. Advice around that would be reasonable. Deprecate @prefix altogether, go a different route - that doesn't seem viable. 14:55:52 PROPOSAL: Close ISSUE-120: @prefix limit - no normative changes to the spec. Add best practices section about content encoding, browser content encoding sniffing, and @prefix on the root and HEAD elements. 14:56:19 q+ 14:56:29 ack gkellogg 14:57:23 Gregg: If I look at some of my own implementations - it's not practical to put prefixes on root element or BODY... ends up going on some chunk that are output. Issue may be that the same prefix not be re-defined. @prefixes should be created at some well-defined level. 14:57:35 Gregg: the real copy-paste problem might be that they're re-defined or not defined at all. 14:57:45 Note: If a document uses an encoding other than UTF-8, and the document declares many prefix mappings, the document SHOULD NOT declare all of those prefixes on the root element because implementations may have trouble determining the encoding of the document. 14:58:08 Gregg: We also found when trying to parse HTML documents - we don't know whether they're RDFa or Microdata - you can't do it at the top of the document - you have to parse the entire document to know whether it is RDFa or Microdata or both. 14:58:34 PROPOSAL: Close ISSUE-120: @prefix limit - no normative changes to the spec. Add best practices section about content encoding, browser content encoding sniffing, and @prefix on the root and HEAD elements. 14:59:18 q+ 14:59:21 Zakim, unmute me 14:59:32 MacTed should no longer be muted 15:00:00 Ted: Add something to talk about what happens when you don't do this. 15:00:22 Gregg: Add bit about grouping @prefix in some logical fashion in the document. 15:00:32 PROPOSAL: Close ISSUE-120: @prefix limit - no normative changes to the spec. Add best practices section about content encoding, browser content encoding sniffing, and @prefix on the root and HEAD elements. 15:00:35 Note: If a document uses an encoding other than UTF-8, and the document declares many prefix mappings, the document SHOULD NOT declare all of those prefixes on the root element because implementations that use so-called 'content sniffing' may have trouble accurately determining the encoding of the document. 15:00:36 +1 15:00:37 +1 15:00:39 +1 15:00:40 +1 15:00:42 +1 15:00:44 +1 15:00:53 RESOLVED: Close ISSUE-120: @prefix limit - no normative changes to the spec. Add best practices section about content encoding, browser content encoding sniffing, and @prefix on the root and HEAD elements. 15:02:00 PROPOSAL: Add best practice specifying that @prefix declarations should be grouped together in some logical fashion and shouldn't be spread haphazardly across the document. The same prefix should not be defined w/ two different meanings in the same document. 15:02:17 +1 15:02:18 +1 15:02:19 +1 15:02:20 +1 15:02:23 +1 15:03:09 RESOLVED: Add best practice specifying that @prefix declarations should be grouped together in some logical fashion and shouldn't be spread haphazardly across the document. The same prefix should not be defined w/ two different meanings in the same document. 15:03:49 ACTION: Shane to add test about @prefix use. 15:03:49 Created ACTION-90 - Add test about @prefix use. [on Shane McCarron - due 2011-08-25]. 15:04:43 -MacTed 15:04:49 -gkellogg 15:04:54 -ShaneM 15:05:01 -manu 15:05:03 -scor 15:06:00 -lindstream 15:06:04 SW_RDFa()10:00AM has ended 15:06:06 Attendees were lindstream, manu, gkellogg, +358.405.25aaaa, MacTed, ShaneM, scor 15:46:23 lindstream has left #rdfa 15:52:01 ShaneM has left #rdfa 17:28:49 Zakim has left #rdfa