Chatlog 2011-10-13

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

13:46:37 <RRSAgent> RRSAgent has joined #rdfa
13:46:37 <RRSAgent> logging to http://www.w3.org/2011/10/13-rdfa-irc
13:46:39 <trackbot> RRSAgent, make logs world
13:46:39 <Zakim> Zakim has joined #rdfa
13:46:41 <trackbot> Zakim, this will be 7332
13:46:41 <Zakim> ok, trackbot; I see SW_RDFa()10:00AM scheduled to start in 14 minutes
13:46:42 <trackbot> Meeting: RDF Web Applications Working Group Teleconference
13:46:42 <trackbot> Date: 13 October 2011
13:47:40 <manu1> Agenda: http://lists.w3.org/Archives/Public/public-rdfa-wg/2011Oct/0020.html
13:47:42 <manu1> Guest: Niklas (lindstream) Lindström
13:47:42 <manu1> Guest: Henri (bergie) Bergius
13:47:42 <manu1> scribenick: scor
13:48:42 <ShaneM> ShaneM has joined #rdfa
13:54:32 <SebastianGermesin> SebastianGermesin has joined #rdfa
13:57:49 <ShaneM> ShaneM has joined #rdfa
13:59:21 <niklasl> niklasl has joined #rdfa
13:59:26 <Zakim> SW_RDFa()10:00AM has now started
13:59:33 <Zakim> +??P25
13:59:41 <gkellogg> zakim, I am ??P25
13:59:41 <Zakim> +gkellogg; got it
13:59:43 <Zakim> + +1.540.961.aaaa
13:59:54 <manu1> zakim, I am aaaa
13:59:54 <Zakim> +manu1; got it
14:00:44 <Zakim> +??P33
14:00:45 <Zakim> +??P37
14:01:04 <Zakim> +McCarron
14:01:04 <niklasl> zakim, I am ??P37
14:01:06 <Zakim> +niklasl; got it
14:01:18 <Knud> zakim, I am ??P33
14:01:22 <Zakim> +Knud; got it
14:01:54 <Zakim> + +68185775aabb
14:01:57 <SebastianGermesin> Zakim, I am aabb
14:02:00 <Zakim> +SebastianGermesin; got it
14:02:39 <Zakim> +scor
14:04:52 <manu1> zakim, who is on the call?
14:04:52 <Zakim> On the phone I see gkellogg, manu1, Knud, niklasl, McCarron, SebastianGermesin, scor
14:08:27 <scor> scor has joined #rdfa
14:09:10 <manu1> Agenda: http://lists.w3.org/Archives/Public/public-rdfa-wg/2011Oct/0020.html
14:09:37 <scor> zakim, who is on the phone?
14:09:39 <Zakim> On the phone I see gkellogg, manu1, Knud, niklasl, McCarron, SebastianGermesin, scor
14:09:50 <manu1> Topic: ISSUE-111: Determine behavior when @inlist and @rev are used together
14:10:40 <gkellogg> q+
14:10:48 <manu1> ack gkellogg
14:10:51 <scor> manu1: has anyone implemented @inlist or @rev in their processor?
14:11:03 <niklasl> q+
14:11:22 <scor> gkellogg: I didn't include it yet... @rev, when used with @inlist, has no effect in the current spec. 
14:11:40 <manu1> ack niklasl
14:12:10 <scor> niklasl: the idea was that @rev used with @inlist might be useful to make a link back to the list itself
14:12:34 <scor> ... it might introduce problems, though - you can only make reverse links to resources, not literals.
14:13:02 <scor> manu1: Ivan has implemented something, but there are issues with how to interpret that with other RDFa attributes?
14:13:22 <scor> gkellogg: @rev not doing anything with @inlist is not a proposal, it's the existing behavior. question is: do we want to keep it that way?
14:13:34 <niklasl> q+
14:13:42 <scor> ... if we don't have an advocate for @inlist we can't make much progress today.
14:14:02 <scor> manu1: Ivan would be that advocate, though he said he didn't really like what it did.
14:14:17 <scor> manu1: The danger is we have an attribute which does not do what we expect it to do. @rev works in every other case in RDFa, so why not with @inlist?
14:14:50 <scor> manu1: one can argue that @inlist it's an advanced feature, and should only be used for advanced use cases
14:14:56 <manu1> ack niklasl
14:15:09 <scor> niklasl: I agree. haven't seen any use case for using the list as a subject - no use cases for @rev and @inlist.
14:15:43 <scor> ... if there were a real use case for it, we could supply the list as subject
14:15:57 <scor> ... we should postpone it until a real use case is found
14:16:18 <scor> manu1: it seems people feel uncomfortable with @inlist and @rev used together
14:16:27 <scor> manu1: anyone disagree?
14:17:00 <scor> manu1: We should not make a decision on this call today - let's wait until Ivan and Toby can give their input.
14:17:18 <SebastianGermesin> ok, for waiting
14:17:52 <scor> Shane: You could send out a proposal to take effect in 7 days if nobody objects.
14:18:15 <scor> Shane: we should solicit Jeni's opinion
14:18:21 <manu1> ACTION: Manu to write proposal to not support @rev/@inlist to not support for 7 days cc Jeni Tennison.
14:18:22 <trackbot> Created ACTION-98 - Write proposal to not support @rev/@inlist to not support for 7 days cc Jeni Tennison. [on Manu Sporny - due 2011-10-20].
14:18:39 <manu1> Topic: ISSUE-108: Refine/deprecate Link relations
14:18:57 <manu1> http://www.w3.org/2010/02/rdfa/track/issues/108
14:20:21 <scor> manu1: one approach we can take it accept only the values specified by HTML5
14:21:01 <scor> manu1: another approach is that the initial list could be the same as the XHTML values we have now, and wait until the new values are standardized to add them
14:21:25 <scor> manu1: another approach is to remove stylesheet, since those triples are not really useful and people don't like them.
14:21:40 <gkellogg> The Microdata spec removed alternate and stylesheet and replaced them with ALTERNATE-STYLESHEET
14:21:42 <scor> manu1: maybe we should also remove alternate as it's not used the way we would expect it in RDF
14:22:47 <scor> Shane: alternate has valid use cases, linking to RSS documents, for instance.
14:23:20 <gkellogg> q+
14:23:49 <manu1> ack gkellogg
14:24:35 <scor> gkellogg: Microdata used to do this in an earlier version of the spec: ALTERNATE-STYLESHEET
14:25:05 <scor> Shane: we don't care about the RDF generated by stylesheet
14:26:06 <scor> manu1: We could hold off on generating alternate or stylesheet triples until the processer would have processed all values in @rel to decide what value should be generated... alternate, stylesheet, or alternate-stylesheet
14:26:35 <scor> manu1: we want to generate useful triples for people on the semantic web. stylesheet and alternative are usually not useful.
14:26:54 <scor> ... people who need these would not use RDF for the purpose of alternative and stylesheet, they would use a different type of application framework.
14:27:07 <niklasl> .. I agree: stylesheet without content is reasonably quite useless
14:27:19 <niklasl> .. i.e. without the html
14:27:43 <niklasl> q+
14:27:49 <scor> manu1: Shane made a point not to remove alternate as it can link to alternate representation (RSS)
14:27:49 <manu1> ack niklasl
14:28:15 <scor> niklasl: we could also say that if @rel contains stylesheet we would ignore the @rel
14:28:51 <scor> manu1: is anybody depending on @rel alternate? I would be surprised if there was any, but have no data to back that up.
14:29:11 <scor> niklasl: I think there is a potential for it, I would probably use dc:hasFormat for that use case though
14:29:31 <scor> manu1: RDFa has been around since 2008, if today there is no use case today, there probably won't be - we should remove it.
14:29:49 <scor> manu1: in the vast majority of the use case, it generates the wrong triples anyway. HTML->alternate->CSS is flat out wrong.
14:31:23 <scor> Shane: on ALTERNATE-STYLESHEET: collection of value in the vocab document. if the HTML WG is randomly introducing new terms with semantics, there is potential for conflicts. e.g. role. is anyone worried about that?
14:31:36 <scor> manu1: we would raise an issue in the HTML WG if this were to happen
14:31:42 <scor> ... that's all we can do, depend on W3C Process to prevent screw-ups like that.
14:33:47 <scor> manu1: the only thing we're talking about is the removal of stylesheet and alternate
14:33:55 <scor> manu1: anyone disagree? or want to add something?
14:34:18 <ShaneM> ShaneM has joined #rdfa
14:34:44 <manu1> ACTION: Shane to respond to mailing list with pointer to discussion today about alternate/stylesheet
14:34:44 <trackbot> Created ACTION-99 - Respond to mailing list with pointer to discussion today about alternate/stylesheet [on Shane McCarron - due 2011-10-20].
14:35:03 <manu1> Topic: First IRI in @typeof determines the vocabulary used
14:35:12 <manu1> http://lists.w3.org/Archives/Public/public-rdfa-wg/2011Oct/0016.html
14:35:26 <manu1> scor: I'm not the first one to propose this - some background.
14:35:53 <manu1> scor: @vocab was introduced to make it easier to author content - to avoid using prefixes/CURIEs - so that was good, makes the markup easier.
14:36:30 <manu1> scor: I think a burden remains - people that come from Microdata - there is a new concept that they have to understand - vocabularies. It's one more thing that people have to learn.
14:36:56 <manu1> scor: Microdata solves this problem by just saying that the itemtype is the base vocabulary (implicitly).
14:37:41 <manu1> scor: I was wondering if RDFa could adapt the same approach as Microdata - give the option of extracting the vocabulary from the first item in @typeof
14:38:22 <manu1> scor: The only difference is that @vocab becomes optional - you can remove vocab and put the full URI of the type in @typeof... processors would infer the vocabulary from the first IRI in @typeof.
14:38:37 <manu1> scor: We could allow for CURIEs in @typeof if the prefix is described somewhere in the document.
14:39:00 <manu1> scor: So you could have something like typeof="skos:Concept" and then the skos URL would become the default @vocab.
14:39:12 <gkellogg> q+
14:39:20 <manu1> ack gkellogg
14:40:13 <manu1> gkellogg: I was uncomfortable with this feature in Microdata... in RDFa it seems dangerous - it doesn't solve all of the problems you want. It's common to use properties from other vocabs like Dublin Core with schema.org - it seems unnatural for RDFa to be able to do that.
14:40:16 <scor> q+
14:40:29 <manu1> gkellogg: RDFa just has other mechanisms to make this easier.
14:40:50 <manu1> scor: I'm not saying RDFa should drop everything else, just add this to make markup easier for those coming from a Microdata world.
14:41:15 <niklasl> q+
14:41:20 <manu1> scor: This is just a shortcut to not use @vocab.
14:41:21 <manu1> ack scor
14:41:49 <manu1> scor: The idea is that people that come from Microdata could make the change easily. It's just a search/replace.
14:42:12 <scor> q+
14:42:31 <manu1> niklasl: I think I agree with Toby - who proposed this initially, and has since come around to not supporting this feature. There are problems with this approach - like what happens when you do chaining - there are technical issues.
14:42:34 <manu1> ack niklasl
14:43:04 <manu1> niklasl: This might be a bit too magical, rather than the explicit use of @vocab.
14:43:07 <manu1> ack scor
14:44:10 <manu1> scor: I don't know if there is a problem with @vocab. re: Chaining - I believe that Microdata use cases will not use that. Raising this proposal from Microdata perspective. This is so that people can convert Microdata to RDFa easily. This feature will only be used with simple markup.
14:44:14 <manu1> aq+
14:44:16 <manu1> q+
14:45:51 <manu1> niklasl: I kind of see your point - but there are issues. If I use full IRIs with this mechanism, that would also set the @vocab. @vocab specifies the namespace - but so does @typeof... that may be confusing - that's what Microdata kinda does. 
14:46:13 <manu1> How do we know how to process the @typeof IRI in a deterministic way?
14:46:52 <manu1> Is conversion from Microdata to RDFa a use case we care about?
14:47:07 <manu1> niklasl: How is the vocabulary determined?
14:47:25 <manu1> gkellogg: Everything after the slash or hash - which is different from Hixie's spec.
14:47:58 <manu1> niklasl: Yes, this is aligned with schema.org - that's what you'd expect.
14:48:16 <manu1> gkellogg: and this is why we did it that way.
14:48:27 <manu1> niklasl: Microdata dropped any conversion to RDF... where are we on that?
14:48:40 <gkellogg> https://dvcs.w3.org/hg/htmldata/raw-file/24af1cde0da1/microdata-rdf/index.html#generate-the-triples
14:48:41 <manu1> gkellogg: HTML Data TF has responsibility to document how to convert Microdata to RDF.
14:49:28 <niklasl> This is an issue, no? <div vocab="http://purl.org/dc/terms/"><div typeof="bibo:LegalDocument"><p property="title">
14:50:57 <scor> manu1: it is not if you don't know that you can use @vocab
14:51:04 <scor> q+
14:53:09 <manu1> manu1: I don't know if we should care about this use case, if people have a reason to migrate from Microdata to RDFa, they will find a way to do it. Having to learn about the concept of a vocabulary doesn't seem like a high barrier to me. It may be dangerous to do a global search/replace of @itemtype with @typeof.
14:53:12 <manu1> ack manu1
14:53:16 <manu1> ack scor
14:53:36 <manu1> scor: I agree if you know that @vocab exists - it's not a problem... but if you don't know it exists - then it's difficult to learn that new concept.
14:53:51 <manu1> scor: However, with this, it's not as confusing - people don't have to learn about @vocab - they just use @typeof.
14:54:04 <manu1> q+
14:54:09 <manu1> ack manu1
14:56:21 <manu1> manu1: The mechanism to break the Microdata IRI into vocab is confusing, they'd have to learn that algorithm instead of @vocab. They already have to understand that there is a vocabulary somewhere.
14:57:02 <manu1> scor: RDFa has a mixture of attributes to be added to markup - in Microdata you just have @itemtype... in RDFa you have @vocab and @typeof.
14:57:21 <manu1> manu1: Ok, we have discussed this thoroughly enough - is there any other information that we would need to understand to make an educated straw-poll on this item?
15:00:49 <manu1> PROPOSAL: Add functionality to @typeof where if the first token is an IRI, that sets the default vocabulary for processing.
15:01:03 <gkellogg> -1
15:01:04 <Knud> -1
15:01:04 <SebastianGermesin> +1
15:01:05 <niklasl> -1
15:01:07 <ShaneM> -1
15:01:08 <scor> scor: +1
15:01:08 <manu1> -1
15:01:49 <manu1> RESOLVED: Do not add functionality to @typeof where if the first token is an IRI, that sets the default vocabulary for processing.
15:01:35 <manu1> Topic: Schema.org supports RDFa in Rich Snippet Tool
15:01:38 <manu1> Good news, schema.org supports RDFa in the Rich Snippet Testing Tool now. Let's all try to support them in implementing RDFa for schema.org
15:02:15 <scor> http://openspring.net/blog/2011/09/30/schemaorg-rich-snippets-drupal-7-rdfa
# SPECIAL MARKER FOR CHATSYNC.  DO NOT EDIT THIS LINE OR BELOW.  SRCLINESUSED=00000167