Warning:
This wiki has been archived and is now read-only.
Chatlog 2010-10-07
From RDFa Working Group Wiki
See CommonScribe Control Panel, original RRSAgent log and preview nicely formatted version.
13:53:58 <RRSAgent> RRSAgent has joined #rdfa 13:53:58 <RRSAgent> logging to http://www.w3.org/2010/10/07-rdfa-irc 13:54:00 <trackbot> RRSAgent, make logs world 13:54:00 <Zakim> Zakim has joined #rdfa 13:54:02 <trackbot> Zakim, this will be 7332 13:54:02 <Zakim> ok, trackbot; I see SW_RDFa()10:00AM scheduled to start in 6 minutes 13:54:03 <trackbot> Meeting: RDFa Working Group Teleconference 13:54:03 <trackbot> Date: 07 October 2010 13:57:22 <Benjamin> Benjamin has joined #rdfa 13:57:41 <manu> Agenda: http://lists.w3.org/Archives/Public/public-rdfa-wg/2010Oct/0030.html 13:57:50 <manu> Chair: Manu 13:57:56 <manu> Present: Manu, Ivan, Steven, ShaneM, Benjamin 13:57:57 <manu> Regrets: MarkB, Knud 13:59:59 <Zakim> SW_RDFa()10:00AM has now started 14:00:06 <Zakim> +manu 14:01:55 <Zakim> + +63.12.057.5aaaa 14:02:12 <ShaneM> ShaneM has joined #rdfa 14:02:24 <Zakim> +ShaneM 14:02:25 <Benjamin> zakim, aaaa is Benjamin 14:02:25 <Zakim> +Benjamin; got it 14:02:37 <Steven> zakim, dial steven-617 14:02:37 <Zakim> ok, Steven; the call is being made 14:02:37 <Zakim> +Steven 14:02:49 <ivan> zakim, dial ivan-voip 14:02:53 <Zakim> ok, ivan; the call is being made 14:03:01 <Zakim> +Ivan 14:03:53 <manu> scribe: manu 14:03:58 <manu> scribenick: manu 14:04:03 <manu> zakim, who is on the call? 14:04:03 <Zakim> On the phone I see manu, Benjamin, ShaneM, Steven, Ivan 14:04:06 <ivan> zakim, mute me 14:04:13 <Zakim> Ivan should now be muted 14:04:38 <manu> Agenda is here: http://lists.w3.org/Archives/Public/public-rdfa-wg/2010Oct/0030.html 14:04:51 <manu> Manu: any updates on RDFa? 14:05:08 <manu> Steven: Added Overstock news to RDFa blog 14:06:04 <manu> Manu: Observer also is publishing RDFa 14:09:14 <ivan> iswc 14:10:14 <ivan> q+ 14:10:21 <manu> ack ivan 14:11:25 <manu> q+ to discuss technical issues and their response 14:13:22 <manu> Manu: Been talking with some very large content industries about RDFa - they're very interested, starting to work with and adopt RDFa in a very big way. 14:13:59 <manu> Topic: ISSUE-20: Deep Processing of XMLLiterals 14:14:05 <manu> http://www.w3.org/2010/02/rdfa/track/issues/20 14:14:45 <manu> Manu: Do we want to support the deep processing of XMLLiterals? 14:16:39 <manu> Manu explains why this is a problem for Drupal, CMS systems. 14:16:50 <manu> Ivan: If something is a literal, processing stops at that moment. 14:16:57 <manu> Ivan: The content of the literal is forgotten for RDFa. 14:17:29 <manu> Ivan: The question is whether we should generate the literal and if we should continue to process the contents of the literal. 14:17:50 <manu> Steven: If you put <body property="foo:bar" datatype="rdf:XMLLiteral">...</body> then nothing would be accessible on the body. 14:17:54 <manu> Shane: Yes, that's correct. 14:18:11 <manu> Manu: I think we should support this. 14:18:35 <manu> Ivan: I don't see any reason why we wouldn't support this - we're adding more triples, not changing ones that already exist. 14:18:41 <manu> Ivan: Pretty trivial change in the processing instructions. 14:19:05 <manu> Ivan: Editorially, it's a bit more complicated - we do have a processing step whether or not we do/do not do recursion. 14:19:15 <ShaneM> q+ to suggest making it optional 14:19:18 <manu> Ivan: We should say, we always do recursion if the change is accepted. 14:19:20 <manu> ack 14:19:21 <manu> ack manu 14:19:21 <Zakim> manu, you wanted to discuss technical issues and their response 14:19:23 <manu> ack shanem 14:19:23 <Zakim> ShaneM, you wanted to suggest making it optional 14:19:39 <manu> Shane: I think there is a use case here that says that this should be optional behavior. 14:20:05 <manu> Shane: Do you think they'd be okay with enabling this as an optional feature? 14:20:12 <manu> Ivan: That sounds sexy, but not sure how we'd do that. 14:20:28 <manu> Ivan: things become complicated in that case, maybe. 14:20:44 <manu> Ivan: Mark raised the issue where we have a mechanism where some features of the process can be controlled. 14:20:58 <manu> Ivan: Not an attribute in the XML sense, but a command parameter passed to the parser. 14:21:06 <manu> Ivan: Wondering if its worth the trouble to do that. 14:21:28 <manu> q+ to focus on yes/no question to support deep processing. 14:21:37 <manu> Shane: Adding another attribute has weight 14:22:01 <manu> Shane: We've already made a major change in this area - only place we've changed backwards compatibility 14:22:10 <manu> Shane: Now we're making a stronger change to XMLLiteral 14:22:21 <manu> Shane: In 1.1 we get a plain literal instead of an XMLLiteral now. 14:22:33 <manu> Shane: So, now if I want an XMLLiteral, I have to request it 14:23:10 <manu> Shane: Today, right now, for RDFa 1.0 you can explicity say that the datatype is rdf:XMLLiteral - and that has the same behavior if you didn't specify the datatype in 1.0 14:23:23 <manu> Shane: In all of my RDFa that I produce right now, I say rdf:XMLLiteral so that I'm forward compatible. 14:23:32 <manu> Shane: Presumably, anybody that is in the know is doing the same thing now, but 14:23:51 <manu> Shane: A 1.0 parser in that mode is going to produce fewer triples than a 1.1 parser - don't know if that's bad or not. 14:24:00 <manu> Ivan: Let's put it this way, formally speaking, this is not a problem. 14:24:20 <manu> Ivan: All we're saying is that 1.0 triples are still generated, but now we have even more triples that are generated. 14:24:35 <manu> Ivan: Charter-wise this is not a problem 14:24:44 <manu> Ivan: Socially, this might be a problem... 14:25:04 <manu> Ivan: Difficult to say if that's a problem - I'm not sure that XMLLiterals were used very frequently in 1.0 in the first place. 14:25:27 <manu> ack manu 14:25:27 <Zakim> manu, you wanted to focus on yes/no question to support deep processing. 14:25:50 <ivan> <span proberty="blab"><span rel="sfasdfa" resource="werwrw">asdfasd</span></span> 14:26:23 <manu> Ivan: In 1.1 the property 'blab' will be a plain literal. 14:26:45 <manu> Ivan: Even if this is a plain literal, the sfasdfa will be generated as well. 14:27:00 <ivan> zakim, mute me 14:27:00 <Zakim> Ivan should now be muted 14:27:12 <ivan> zakim, unmute me 14:27:12 <Zakim> Ivan should no longer be muted 14:27:36 <manu> <div property="dcterms:content"> foo bar <span rel="next" resource="foo">asdfasd</span></div> 14:27:50 <manu> Ivan: So in 1.0, that would've been an XMLLiteral. 14:28:36 <manu> Shane: But, according to the spec, sequence step 11, the recurse is only set to false when you're talking about an XMLLiteral 14:28:44 <manu> Shane: Plain content recurses anyway 14:28:57 <manu> <div property="dcterms:content" datatype="rdf:XMLLiteral"> foo bar <span rel="next" resource="foo">asdfasd</span></div> 14:30:04 <manu> Shane: If I have a plain literals, or datatype="" - you recurse 14:30:13 <manu> Shane: Processing continues 14:31:46 <manu> Manu: So, the issue here is that you don't recurse in the very specific case listed above (property and datatype of XMLLIteral) 14:32:08 <manu> Ivan: There is no good reason why we shouldn't deeply process the XMLLiteral. 14:32:21 <manu> Shane: The changes to the spec are trivial 14:33:15 <ShaneM> The CHANGE to make is that we remove references to the recuse flag. There is no reason to do anything more complicated. 14:33:39 <Zakim> -Steven 14:33:47 <Steven> zakim, cal steven-617 14:33:47 <Zakim> I don't understand 'cal steven-617', Steven 14:33:55 <manu> PROPOSAL: Remove the recurse flag from the Syntax Processing rules in RDFa Core. 14:33:56 <Steven> zakim, call steven-617 14:33:56 <Zakim> ok, Steven; the call is being made 14:33:58 <Zakim> +Steven 14:34:01 <ivan> +1 14:34:02 <manu> Manu: +1 14:34:03 <ShaneM> +1 14:34:05 <Benjamin> +1 14:34:07 <Steven> +1 14:35:16 <manu> RESOLVED: Remove the recurse flag from the Syntax Processing rules in RDFa Core. 14:35:36 <manu> Topic: ISSUE-46: Automatic conversion of plain literals into IRIs 14:35:46 <manu> http://www.w3.org/2010/02/rdfa/track/issues/46 14:35:52 <ShaneM> I have made the changes to the source. 14:36:44 <Steven> q+ 14:37:10 <manu> Manu explains the plain literal vs. IRI issue. 14:37:13 <ivan> q+ 14:37:18 <ivan> ack Steven 14:37:37 <manu> <meta property="ogp:url" content="http://example.org/person#webid" /> 14:37:55 <manu> Steven: I have nothing against the principle, but I do have feelings about how we should do it. 14:37:59 <manu> ack steven 14:38:01 <manu> ack ivan 14:38:14 <manu> Ivan: My approach - the way we would do that is to exclude literals that contain spaces 14:38:25 <manu> Ivan: I know that in IRI, you can have space, but SPARQL has already excluded that 14:38:41 <manu> Ivan: I'd only support absolute URIs with a scheme that is officially registered by IETF. 14:39:03 <manu> q+ to say how we could do this via default language RDFa Profile. 14:39:20 <manu> Steven: you have to keep the list of IRIs up to date, right? 14:39:33 <ShaneM> q+ to speak against this change 14:39:39 <manu> Ivan: There is a regular expression that can support this stuff. 14:39:45 <manu> Ivan: The regex is pretty easy 14:40:00 <manu> Ivan: We could encode this as a regex. 14:40:11 <manu> Ivan: not a big deal to implement it. 14:40:27 <manu> Steven: If I said that I would have less problems with this if datatype="iri" what would you say? 14:40:34 <manu> Ivan: The use case isn't to add datatype="iri" 14:40:45 <manu> Steven: We're doing this to program around a bug in someone elses markup. 14:41:17 <manu> Ivan: The bug isn't really a "bug" - it's shared by some very large companies supporting RDFa. 14:41:34 <manu> Ivan: I realize that this is not ideal - the reason to have rel goes away, it's a modelling bug, etc. 14:42:04 <manu> Ivan: There are two approaches to this - everybody else has to educate themselves and do it properly, or we have to make a step that makes the RDF data that is harvested really nice. 14:42:11 <manu> Ivan: Education doesn't really work. 14:42:25 <manu> ack manu 14:42:25 <Zakim> manu, you wanted to say how we could do this via default language RDFa Profile. 14:42:49 <manu> We could add something like this: rdfa:allowedScheme "http" 14:42:53 <manu> and this: rdfa:allowedScheme "ftp" 14:42:55 <manu> and this: rdfa:allowedScheme "mailto" 14:43:14 <manu> ack shanem 14:43:14 <Zakim> ShaneM, you wanted to speak against this change 14:43:40 <ivan> q+ 14:43:49 <manu> Manu: We have a default language profile, we could embed stuff in there. 14:44:27 <manu> Shane: I agree with Steven - this is a problem - if RDF says that an object literal isn't a resource, then it isn't a resource. 14:44:38 <manu> Shane: We are just an RDF serialization, we shouldn't change the rules. 14:44:42 <manu> ack ivan 14:45:07 <manu> Ivan: If it were only one company, I'd agree with you 14:45:31 <manu> Ivan: but it's more than just one company - it's one of the toughest things for many people to understand and accept. 14:45:41 <manu> Ivan: that there is a difference between a URI as a string and a URI as an identifier. 14:45:53 <ShaneM> I note that the TAG debates this at least twice a year. 14:45:54 <manu> Ivan: This is a generic issue, that we know is around RDF. 14:46:06 <manu> Ivan: If I take a serialization like turtle, TURTLE is made for RDF people. 14:46:30 <manu> Ivan: TURTLE makes the differentiation very familiar to people with RDF. 14:46:47 <manu> Ivan: RDFa has a different constituency - it's not primarily done only for RDF people. 14:47:05 <manu> Ivan: It's primarily for people that don't know much about RDF. 14:47:14 <manu> Ivan: Whether they do it right or wrong, they don't care 14:47:23 <Zakim> -ShaneM 14:47:24 <manu> Ivan: At the end of the day, RDF people will not get the right RDF triples. 14:47:38 <Zakim> +ShaneM 14:48:06 <manu> q+ to ask whether or not http://example.org is commonly a string vs. IRI 14:48:23 <manu> Ivan: one of the approaches that mark had in his mail is to limit it to the meta element. 14:48:27 <ShaneM> if we are going this way, then I would prefer Manu's strategy of declaring interesting shortcut schemes 14:48:49 <manu> Ivan: I can live with things the way they are 14:49:05 <manu> ack manu 14:49:05 <Zakim> manu, you wanted to ask whether or not http://example.org is commonly a string vs. IRI 14:49:35 <manu> datatype="" 14:52:28 <manu> Steven: Why do we have to embed Facebook's mistake in the language. 14:52:50 <manu> Manu: It's a very good point. 14:53:03 <manu> Ivan: My goal is to get as much of the data out there, collectable in proper RDF as possible. 14:53:23 <manu> Ivan: If half of the web community is uneducated, we have to live with that, and we have to try and understand what they want to do. 14:53:46 <manu> Ivan: I realize this is intellectually ugly - the other alternative is to not care about how this stuff is being marked up right now. 14:54:16 <manu> Steven: Why is this bad RDF? The property states that the resource is a URL that just happens to be a string. It's one level more of indirection. 14:55:03 <manu> Ivan: What will happen is that we will push the ugliness elsewhere - people will define various vocabularies - proper ontologies will say you should have a URI reference, but the people that are generating the RDF generating strings instead of URIs 14:55:18 <manu> Ivan: We can map to any RDF that we want. 14:55:39 <Benjamin> q+ to ask why not add just an informal developer hint to the spec about how to be facebook compatible 14:55:55 <manu> Ivan: It's the way we interpret the XHTML+RDFa when we generate the triples. 14:56:06 <ivan> ack Benjamin 14:56:06 <Zakim> Benjamin, you wanted to ask why not add just an informal developer hint to the spec about how to be facebook compatible 14:56:08 <manu> Steven: This is very creaky to me - trying to figure out what a proper URI is. 14:56:32 <manu> Benjamin: We shouldn't not add a bug fix of someone else to the spec - we should be compatible with most of the data - could we add an informal hint to developers. 14:56:42 <manu> Ivan: They know that, Benjamin. 14:57:00 <manu> Benjamin: They won't change it, sure - but we can educate developers so that others may not make the same mistake. 14:57:04 <ShaneM> q+ to followup on ben's comment 14:57:15 <manu> Benjamin: And we do that without changing the spec. 14:58:27 <manu> Shane: We could provide guidance in the wiki on this. 14:58:30 <manu> q+ to end the telecon 14:58:33 <manu> ack shanem 14:58:33 <Zakim> ShaneM, you wanted to followup on ben's comment 14:58:57 <manu> Steven: Perhaps if we can identify the properties should be IRIs via plain literals 14:59:05 <manu> Steven: Could we state something about this in the RDFa Profile? 14:59:23 <manu> Steven: If you follow-your-nose to the property, it could say what the appropriate range is? 15:00:09 <manu> Ivan: You could have declarations in the vocabulary document, yes. 15:00:32 <manu> Shane: only some of the OGP properties take resources. 15:01:11 <manu> ack manu 15:01:12 <Zakim> manu, you wanted to end the telecon 15:03:06 <manu> Steven: I don't mind if we have processing instructions in RDFa Profile that say ogp:url should be a IRI 15:03:12 <manu> Ivan: There are two issues here. 15:03:15 <manu> Manu: Let's continue the discussion on the mailing list, however it sounds like we do not have consensus currently to add this into the spec as currently proposed. 15:06:43 <Zakim> -ShaneM 15:06:45 <ivan> zakim, drop me 15:06:45 <Zakim> -manu 15:06:45 <Zakim> Ivan is being disconnected 15:06:46 <Zakim> -Ivan 15:06:46 <Zakim> -Steven 15:06:47 <Zakim> -Benjamin 15:06:48 <Zakim> SW_RDFa()10:00AM has ended 15:06:50 <Zakim> Attendees were manu, +63.12.057.5aaaa, ShaneM, Benjamin, Steven, Ivan 15:10:24 <ShaneM> ShaneM has left #rdfa # SPECIAL MARKER FOR CHATSYNC. DO NOT EDIT THIS LINE OR BELOW. SRCLINESUSED=00000216