Chatlog 2011-08-18

From RDFa Working Group Wiki
Jump to: navigation, search

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

13:56:24 <RRSAgent> RRSAgent has joined #rdfa
13:56:24 <RRSAgent> logging to http://www.w3.org/2011/08/18-rdfa-irc
13:56:26 <trackbot> RRSAgent, make logs world
13:56:26 <Zakim> Zakim has joined #rdfa
13:56:28 <trackbot> Zakim, this will be 7332
13:56:28 <Zakim> ok, trackbot; I see SW_RDFa()10:00AM scheduled to start in 4 minutes
13:56:29 <trackbot> Meeting: RDF Web Applications Working Group Teleconference
13:56:29 <trackbot> Date: 18 August 2011
13:56:33 <manu> Agenda: http://lists.w3.org/Archives/Public/public-rdfa-wg/2011Aug/0034.html
13:56:38 <manu> Chair: Manu
13:56:38 <manu> Guest: Stéphane (scor) Corlosquet
13:56:38 <manu> Guest: Henri (bergie) Bergius
13:56:38 <manu> Guest: Niklas (lindstream) Lindström
13:57:23 <Zakim> SW_RDFa()10:00AM has now started
13:57:30 <Zakim> +??P2
13:57:48 <lindstream> zakim, I am ??P2
13:57:48 <Zakim> +lindstream; got it
13:58:44 <Zakim> +??P14
13:58:49 <manu> zakim, I am ??P14
13:58:49 <Zakim> +manu; got it
13:59:04 <Zakim> +??P8
13:59:18 <gkellogg> zakim, I am ??P8
13:59:18 <Zakim> +gkellogg; got it
13:59:57 <Zakim> +OpenLink_Software
14:00:02 <Zakim> + +358.405.25aaaa
14:00:04 <ShaneM> ShaneM has joined #rdfa
14:00:09 <MacTed> Zakim, OpenLink_Software is temporarily me
14:00:09 <manu> Zakim, aaaa is bergie
14:00:09 <Zakim> +MacTed; got it
14:00:12 <MacTed> Zakim, mute me
14:00:12 <Zakim> MacTed should now be muted
14:01:01 <Zakim> +??P29
14:01:05 <ShaneM> zakim, I am ??P29
14:01:05 <Zakim> +ShaneM; got it
14:02:03 <manu> zakim, who is on the call?
14:02:05 <Zakim> On the phone I see lindstream, manu, gkellogg, MacTed (muted), +358.405.25aaaa, ShaneM
14:02:52 <Zakim> -ShaneM
14:03:49 <Zakim> +??P29
14:03:52 <ShaneM> zakim, I am ??P29
14:03:52 <Zakim> +ShaneM; got it
14:04:12 <manu> scribenick: manu
14:04:43 <manu> Manu: Any other agenda items? Shane, your @profile issue?
14:04:48 <manu> Shane: Not yet, Ivan isn't here. What about Vocabulary Expansion?
14:05:06 <manu> Gregg: Vocabulary Expansion is a parallel issue to @profile.
14:05:20 <manu> Shane: Correct - @profile isn't the long pole in the tent anymore - Vocabulary Expansion is.
14:05:38 <manu> Topic: Vocabulary Expansion Update
14:05:52 <manu> Niklas: Gregg and I haven't coordinated yet - haven't had time - began writing some of the spec text.
14:06:09 <manu> Niklas: Looked at Ivan's text - administrative problem is access to CVS.
14:06:32 <manu> Niklas: I could write the text and and mail it to the list?
14:07:07 <manu> Manu: Gregg has CVS access and adding spec language.
14:07:07 <gkellogg> Gregg: I 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 on spec text, of course.
14:08:34 <manu> Niklas: Could we hack on it on github?
14:08:52 <manu> Manu: I don't think W3c would like that... just send the language to the mailing list, we'll discuss there - have Gregg integrate it.
14:09:08 <MacTed> http://www.w3.org/2010/02/rdfa/wiki/Main_Page
14:09:24 <MacTed> It's a wiki.  It's in w3.  It's a good place for collaborative text building...
14:09:39 <manu> 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> scor has joined #rdfa
14:12:25 <manu> Topic: ISSUE-101: xsd:string coercion
14:12:31 <manu> The issue is here: http://www.w3.org/2010/02/rdfa/track/issues/101
14:12:43 <manu> Started in this thread: http://lists.w3.org/Archives/Public/public-rdfa-wg/2011Jun/0064.html
14:13:47 <gkellogg> q+
14:13:48 <Zakim> +scor
14:14:00 <manu> Manu: Should we add spec text asking implementers change anything that is an xsd:string to a plain literal?
14:14:28 <manu> Gregg: My read of their finding was a bit different - abstract model should use xsd:string datatype for plain literals w/o a language.
14:14:38 <manu> Gregg: Recent communication about how @lang might be handled.
14:14:46 <gkellogg> http://lists.w3.org/Archives/Public/public-rdf-wg/2011Jul/0048.html
14:15:17 <manu> Gregg: One of the issues is how serializations should be managed. I think we do want to follow their lead to not create any extra confusion.
14:15:27 <manu> Manu: Are you saying we need not do anything?
14:15:53 <lindstream> q+
14:15:58 <manu> Gregg: No, we should note the changes to the abstract syntax in the spec - plain literals implicitly get a datatype string, when they're serialized, they're serialized w/o that datatype.
14:16:00 <manu> ack gkellogg
14:16:49 <manu> 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 <manu> 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 <manu> Niklas: Real problem is integration w/ RDF libraries that may not have agreement between the parsers and the serializers.
14:17:55 <manu> ack lindstream
14:19:12 <manu> Manu explains his understanding of the issue.
14:20:02 <lindstream> q+
14:20:16 <manu> Gregg: I'm trying to figure out how this could happen - if you have mixed systems - like raptor/redland ... your parser is in the new style (generating xsd:string) then your serializer must be in the same new style (generating plain literal instead of typed literal w/ xsd:string).
14:20:42 <manu> Gregg: You could have a half-implemented issue there... what happens when parser is new style and serializer is old style?
14:21:52 <manu> Niklas: Semantically, as the RDF WG is defining it - there is no longer a plain literal... 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 <manu> Gregg: The issue has to do w/ how you express the serialization.
14:25:55 <manu> Discussion about what RDFa Processors output - an RDF abstract model - or a serialized stream.
14:25:59 <lindstream> q+
14:26:04 <manu> q+
14:26:22 <manu> Shane: The issue is on the serialized output, not the model - because you don't really have access to the abstract model in many processors.
14:27:03 <manu> Niklas: There are two ways to express a string literals - when reasoned over these things are semantically equivalent. There is nothing wrong with a parser that differentiates between how it picked up the data during the parsing process.
14:27:31 <manu> Niklas: Let's say that semantically, literals w/o datatype are actually literals w/ a datatype xsd:string.
14:28:06 <manu> 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 <gkellogg> 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 <manu> 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 <manu> Niklas: If they were to parse TURTLE, it wouldn't be wrong to preserve that a string was expressed as a plain literal and not an xsd:string in the model - it would be unnecessary semantically - nothing wrong w/ an RDFa parser to denote the syntactic differences.
14:29:34 <manu> Niklas: But there is no longer a semantic difference.
14:30:15 <manu> Manu: So, there is no change I need to make to my parser?
14:30:32 <gkellogg> q+ to discuss Turtle spec language
14:30:36 <manu> ack lindstream
14:30:38 <manu> ack manu
14:31:33 <manu> Manu: I think the real problem is that two processors could generate different triples from one another.
14:31:37 <Zakim> - +358.405.25aaaa
14:32:05 <manu> Niklas: Libraries/serializers are no longer separate - this may cause implementation issues going forward.
14:32:28 <manu> 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 <manu> ack gkellogg
14:32:31 <Zakim> gkellogg, you wanted to discuss Turtle spec language
14:33:12 <gkellogg> 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 <manu> 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> Manu: My concern is having RDFa Processors that generate different triples - are they conformant even if they generate two types of triples?
14:36:55 <manu> Niklas: I see the concern - the triples aren't different anymore at the serialization level.
14:37:13 <manu> Manu: I see this approach creating bugs...
14:38:21 <manu> Manu: Who would update their implementations based on this language?
14:38:24 <manu> Niklas: I would
14:38:30 <manu> Gregg: So would I
14:38:30 <manu> Manu: I don't think I'd do anything.
14:39:01 <manu> Niklas: I would expect that any sort of serialization diffs would disappear when SPARQL serializations changed.
14:39:22 <manu> Shane: I don't know if I'd make any changes.
14:40:22 <manu> Shane: Making us change plain literals to generate xsd:strings now is a backwards-incompatible change.
14:40:44 <manu> Gregg: it would be valid to take xsd:string tagged literals and represent them internally as plain literals.
14:41:29 <manu> 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> Manu: Doesn't RDF API / RDF Interfaces operate on the abstract model? My librdfa processor expresses triples via a callback in abstract model space, not serialization space.
14:44:39 <manu> Manu explains how this may impact librdfa implementation - would remove an object type of OBJECT_TYPE_PLAIN_LITERAL, and only have OT_IRI, OT_TYPED, OT_PLAIN_LITERAL_WITH_LANGUAGE.
14:45:16 <manu> Shane: Abstract model is that of a plain literal w/o datatype tag - still leads to backwards compatibility issue - xsd:string was never intended to be treated differently than plain literal.
14:45:51 <manu> Gregg: I think we should ask for some feedback from the WG.
14:46:11 <manu> ACTION: Gregg to contact Richard in RDF WG about xsd:string coercion.
14:46:12 <trackbot> Created ACTION-89 - Contact Richard in RDF WG about xsd:string coercion. [on Gregg Kellogg - due 2011-08-25].
14:46:40 <manu> Topic: ISSUE-102: @prefix limit
14:46:50 <manu> Issue is here: http://www.w3.org/2010/02/rdfa/track/issues/102
14:48:10 <manu> Raised here http://lists.w3.org/Archives/Public/public-rdfa-wg/2011Jul/0044.html
14:49:54 <ShaneM> q+ to propose we just close this issue.  
14:50:32 <manu> Manu explain the issue
14:50:36 <manu> ack ShaneM
14:50:36 <Zakim> ShaneM, you wanted to propose we just close this issue.
14:51:22 <manu> 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 <lindstream> q+
14:52:28 <manu> Gregg: Yes, we should specify a best practice.
14:52:41 <manu> Niklas: yes, agree - close it - add best practices to the spec. 
14:52:44 <MacTed> +1 best practices guidance, and warnings of what may happen if those are not followed...
14:52:50 <manu> ack lindstream
14:54:32 <manu> 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:56:19 <gkellogg> q+
14:56:29 <manu> ack gkellogg
14:57:23 <manu> 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 <manu> Gregg: the real copy-paste problem might be that they're re-defined or not defined at all.
14:57:45 <ShaneM> 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 <manu> 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:59:18 <MacTed> q+
14:59:21 <MacTed> Zakim, unmute me
14:59:32 <Zakim> MacTed should no longer be muted
15:00:00 <manu> Ted: Add something to talk about what happens when you don't do this - best practices often fail to tell you why something is a best practice.
15:00:22 <manu> Gregg: Add bit about grouping @prefix in some logical fashion in the document.
15:00:32 <manu> 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 <ShaneM> 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 <ShaneM> +1
15:00:37 <manu> Manu: +1
15:00:39 <gkellogg> +1
15:00:40 <lindstream> +1
15:00:42 <MacTed> +1
15:00:44 <scor> +1
15:00:53 <manu> 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 <manu> 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 <gkellogg> +1
15:02:18 <lindstream> +1
15:02:19 <manu> Manu: +1
15:02:20 <MacTed> +1
15:02:23 <ShaneM> +1
15:03:09 <manu> 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 <ShaneM> ACTION: Shane to add test about @prefix use.
15:03:49 <trackbot> Created ACTION-90 - Add test about @prefix use. [on Shane McCarron - due 2011-08-25].
# SPECIAL MARKER FOR CHATSYNC.  DO NOT EDIT THIS LINE OR BELOW.  SRCLINESUSED=00000163