Chatlog 2011-09-01

From RDFa Working Group Wiki
Jump to: navigation, search

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

13:55:29 <RRSAgent> RRSAgent has joined #rdfa
13:55:29 <RRSAgent> logging to http://www.w3.org/2011/09/01-rdfa-irc
13:55:31 <trackbot> RRSAgent, make logs world
13:55:31 <Zakim> Zakim has joined #rdfa
13:55:33 <trackbot> Zakim, this will be 7332
13:55:33 <Zakim> ok, trackbot; I see SW_RDFa()10:00AM scheduled to start in 5 minutes
13:55:34 <trackbot> Meeting: RDF Web Applications Working Group Teleconference
13:55:34 <trackbot> Date: 01 September 2011
13:56:20 <manu1> Guest: Stéphane (scor) Corlosquet
13:56:22 <manu1> Guest: Niklas (lindstream) Lindström
13:56:22 <manu1> Chair: Manu
13:56:25 <manu1> Agenda: http://lists.w3.org/Archives/Public/public-rdfa-wg/2011Aug/0093.html
13:58:00 <Zakim> SW_RDFa()10:00AM has now started
13:58:07 <Zakim> +??P20
13:58:10 <gkellogg> zakim, I am ??P20
13:58:10 <Zakim> +gkellogg; got it
13:59:32 <lindstream> lindstream has joined #rdfa
13:59:43 <Zakim> + +1.781.866.aaaa
14:00:17 <Zakim> - +1.781.866.aaaa
14:01:13 <Zakim> +??P41
14:01:13 <scor> scor has joined #rdfa
14:01:19 <Zakim> +aharon
14:01:21 <ivan> zakim, dial ivan-voip
14:01:23 <Zakim> ok, ivan; the call is being made
14:01:27 <Zakim> +Ivan
14:01:29 <lindstream> zakim, I am ??P41
14:01:35 <Zakim> +lindstream; got it
14:01:47 <Zakim> + +1.781.866.aabb
14:01:58 <tomayac> zakim, i am aaaa
14:02:03 <Zakim> sorry, tomayac, I do not see a party named 'aaaa'
14:02:20 <scor> Zakim, I'm aabb
14:02:21 <Zakim> I don't understand 'I'm aabb', scor
14:02:29 <scor> zakim, aabb is me
14:02:31 <Zakim> +??P49
14:02:33 <Zakim> +scor; got it
14:02:34 <manu1> zakim, I am ??P49
14:02:37 <Zakim> +manu1; got it
14:02:47 <manu1> zakim, who is on the call?
14:02:49 <Zakim> On the phone I see gkellogg, lindstream, aharon, Ivan, scor, manu1
14:03:37 <scor> zakim, who is making noise?
14:03:47 <Zakim> scor, listening for 10 seconds I heard sound from the following: 6 (37%), gkellogg (13%), aharon (34%), manu1 (60%)
14:04:00 <ivan> zakim, aharon is tomayac
14:04:00 <Zakim> +tomayac; got it
14:04:00 <manu1> zakim, who is on the call?
14:04:02 <Zakim> On the phone I see gkellogg, lindstream, tomayac, Ivan, scor, manu1
14:05:55 <ivan> scribenick: ivan
14:06:41 <ivan> manu: the agenda will have to be moved around, one of the items was a closed issue
14:06:52 <ivan> ... we have to respond to netlabs, it is not good to push this off as long as we have, especially since they are interested in the RDFa API.
14:08:08 <ivan> ... any other updates to the agenda?
14:08:15 <ivan> ... none
14:08:22 <manu1> Topic: Response to netlabs.org
14:08:23 <lindstream> +1 on RDFa core prior to API..
14:08:29 <ivan> manu: let us talk about the netlab stuff very quickly
14:08:43 <manu1> We should focus on RDFa Core right now
14:08:52 <manu1> We need to say something to these guys: http://lists.w3.org/Archives/Public/public-rdfa-wg/2011Aug/0033.html
14:09:07 <manu1> ACTION: Manu to respond to netlabs.org folks
14:09:08 <trackbot> Created ACTION-91 - Respond to netlabs.org folks [on Manu Sporny - due 2011-09-08].
14:09:11 <lindstream> q+
14:09:20 <ivan> ack lindstream 
14:09:38 <Zakim> +??P70
14:09:39 <ivan> lindstream: we should say that the api is still in flux, we should tell them that
14:09:49 <ShaneM> ShaneM has joined #rdfa
14:09:52 <ivan> zakim, ??P70 is ShaneM 
14:09:56 <Zakim> +ShaneM; got it
14:10:08 <manu1> Topic: ISSUE-110: graph source triple
14:10:38 <ivan> manu: had some discussion on the mailing list
14:10:57 <gkellogg> q+
14:10:58 <ivan> niklas: I do not have a strong opinion, and I do not think we should do it
14:11:18 <ivan> ... just to highlight my problems I wrote a mail
14:11:30 <ivan> ... we get into a mess on how to name the graph.
14:11:42 <manu1> ack gkellogg
14:11:54 <ivan> gkellogg: i think the problem is that we do not generate a document
14:12:04 <ivan> ... we create a graph
14:12:07 <ivan> ... and a graph has to a fully resolved uri
14:12:20 <ivan> ... so i am not sure we can add a name
14:12:36 <ivan> ... we could do add a triple on a type
14:12:38 <ivan> q+
14:12:42 <manu1> ack ivan
14:12:58 <manu1> Ivan: That was the original proposal
14:13:11 <manu1> Ivan: What I had in mind was this:
14:13:21 <ivan> <URIOFDOCUMENT> a rdfa:Source .
14:14:02 <manu1> Ivan: We can do that without problems, it doesn't raise all of the issues w/o naming. We do not generate a document we generate a graph - unless we introduce the concept of graph naming, we have a problem.
14:14:22 <manu1> Ivan: We can fall back to what I say above. It solves the issue for applications that want to have that information.
14:14:27 <lindstream> .. like an implied <head typeof="rdfa:Source">
14:14:36 <ivan> gkellogg: it is the best we can do
14:14:47 <ivan> ... it is a useful triple to have in the graph
14:14:55 <ivan> ... it does not accomplish what could be doen
14:14:59 <ivan> s/doen/done/
14:15:00 <lindstream> q+
14:15:12 <manu1> ack lindstream
14:15:25 <ivan> lindstream: i see no real problem with it, you can provide that explicitly if you want
14:15:46 <ivan> ... other formats do not do the same
14:15:54 <ivan> ... it would be a new thing for rdfa
14:16:33 <manu1> Ivan: This isn't the same as RDF/XML or TURTLE - the only equivalent is GRDDL - in RDF/XML or TURTLE, you have a self-reference.
14:17:02 <manu1> Ivan: The difference here is you have a source document (the RDFa document) and you process that to generate a graph (the RDF/XML or TURTLE graph).
14:17:39 <manu1> q+ to ask about who is asking for this feature?
14:18:08 <ivan> lindstream: rdfa is an amalgam of the things
14:18:21 <ivan> ... it is something that is 'true' so it does not harm
14:18:26 <manu1> ack manu1
14:18:26 <Zakim> manu1, you wanted to ask about who is asking for this feature?
14:18:35 <ivan> q+
14:18:52 <manu1> ack ivan
14:19:06 <manu1> Manu: Who needs this feature? What use case cannot be solved without it?
14:19:53 <manu1> Ivan: I spoke w/ a company - this company retrieves data via RDFa - then they mix it up with a number of things - they're a search company - but they want to have information about the origin of the data that led to the indexes.
14:20:06 <lindstream> q+ on provenance tracking
14:20:14 <manu1> q+ to ask how this is different from the larger problem of provenance.
14:20:48 <manu1> Ivan: They wanted to have something that says "This is where the triple was created from"
14:20:52 <ivan> lindstream: I do not see how that would help them much
14:21:15 <ivan> ... a provenance tracking 
14:21:21 <lindstream> <{base-uri}> a foaf:Document; dct:format "text/html" .
14:21:21 <ivan> ... is necessary
14:22:06 <ivan> ... it is up to them, ie, their processor, to add additional information about the origin
14:22:08 <manu1> ack lindstream
14:22:08 <Zakim> lindstream, you wanted to comment on provenance tracking
14:22:12 <ivan> q+
14:22:13 <manu1> ack manu1
14:22:13 <Zakim> manu1, you wanted to ask how this is different from the larger problem of provenance.
14:22:43 <ivan> manu1: our company does this as well
14:22:49 <ivan> ... we have to fetch document with rdfa
14:22:59 <ivan> ... we have to track the provenance of the document
14:23:16 <ivan> ... we have to have more than just the origin, like time, mime, etc
14:23:21 <ivan> ... just adding that one triple in there
14:23:41 <ivan> ... will not solve the issues
14:23:59 <ivan> ... if we put this in, i do not think it solves the problem of provenance
14:24:06 <ivan> ... it does not get you closer to the solution
14:24:25 <ivan> ... you have to think about provenance in a larger sense
14:24:27 <manu1> ack ivan
14:24:44 <manu1> Ivan: I don't want to make a big deal out of it - the group isn't in favor of this.
14:25:16 <tomayac> 0 neutral about it
14:26:25 <manu1> PROPOSAL: Do not generate a provenance triple in the default graph for RDFa Core 1.1 processors.
14:26:34 <manu1> +1
14:26:34 <ivan> Ivan: +1
14:26:36 <ShaneM> +1
14:26:37 <lindstream> +1
14:26:38 <gkellogg> +1
14:26:55 <tomayac> 0
14:26:57 <ivan> RESOLVED: Do not generate a provenance triple in the default graph for RDFa Core 1.1 processors. (closing issue-110)
14:27:50 <manu1> Topic: ISSUE-109: 'default graph' vs. 'output graph'
14:27:52 <manu1> http://www.w3.org/2010/02/rdfa/track/issues/109
14:27:56 <ivan> q+
14:28:23 <manu1> Ivan: SPARQL is very specific about what 'default graph' means wrt. data sets.
14:28:44 <manu1> Ivan: It's not good if we re-use the same terms w/ a different meaning - global change of 'default graph' to 'output graph' is a good change.
14:28:54 <lindstream> q+ on naming
14:29:03 <manu1> ack lindstream
14:29:03 <Zakim> lindstream, you wanted to comment on naming
14:29:06 <manu1> ack ivan
14:29:19 <ivan> lindstream: I agree, default graph means something specific
14:29:36 <ivan> ... 'output' or 'result' graph is possible
14:29:48 <ivan> manu1: anybody is against renaming?
14:30:04 <ivan> manu1: anybody prefer 'result graph'?
14:30:58 <manu1> PROPOSAL: Rename 'default graph' to 'output graph' in all RDFa documents.
14:31:02 <ivan> Ivan: +1
14:31:03 <manu1> +1
14:31:03 <lindstream> +1
14:31:03 <gkellogg> +1
14:31:05 <scor> +1
14:31:13 <tomayac> +1
14:31:19 <ivan> RESOLVED:  Rename 'default graph' to 'output graph' in all RDFa documents. (closing issue-109)
14:31:24 <gkellogg> q+ to discuss test suite
14:32:09 <manu1> ack gkellogg
14:32:09 <Zakim> gkellogg, you wanted to discuss test suite
14:32:37 <manu1> Topic: ISSUE-105: @itemref attribute
14:32:40 <manu1> http://www.w3.org/2010/02/rdfa/track/issues/105
14:33:49 <manu1> Manu: I think this is a horrible idea
14:35:04 <ivan> manu1: I have the technical issue with @itemref
14:35:14 <gkellogg> microdata is a tree, not a graph, so @itemref has more use for them
14:35:17 <ivan> .... it is unimplementable if you do not have a DOM
14:35:38 <ivan> ... if I am a one-pass processor then it becomes really difficult if not impossible to do it
14:35:41 <lindstream> q+ on what's the use case (and why wouldn't @rel, @rev or @about solve those?)
14:36:03 <ivan> ... for each @itemref you would have to rescan the document if you use a SAX-based implementation.
14:36:06 <manu1> ack lindstream
14:36:06 <Zakim> lindstream, you wanted to comment on what's the use case (and why wouldn't @rel, @rev or @about solve those?)
14:36:25 <ivan> lindstream: I do not see the use case, we already have powerful constructs 
14:36:41 <ivan> ... maybe if we have a real use case, I believe it would be better to have multiple abouts
14:36:42 <ivan> q+
14:36:47 <manu1> ack ivan
14:37:21 <gkellogg> q+ to discuss relation of @rev to @itemref
14:37:51 <manu1> q+ to say that @itemref is the same as about="a b c", imo
14:39:33 <manu1> ack gkellogg
14:39:33 <Zakim> gkellogg, you wanted to discuss relation of @rev to @itemref
14:39:45 <ivan> gkellogg: I think our use of @rev addresses some of the things 
14:39:55 <ivan> ... ie, to associate different subjects with a given object
14:40:05 <ivan> ... there is already many sources of copy paste issues
14:40:19 <ivan> ... @itemref makes the meaning of attributes different
14:40:23 <manu1> ack manu1
14:40:23 <Zakim> manu1, you wanted to say that @itemref is the same as about="a b c", imo
14:40:25 <ivan> ... it is a whole set of problems
14:40:34 <ivan> ... and I would prefer to keep away from 
14:40:48 <ivan> manu1: the about attribute solves most of the problems
14:40:58 <ivan> ... the about thing solves most of the issues
14:41:10 <ivan> ... i do understand the use case in microdata
14:41:21 <ivan> ... it is not a graph, so they need something like that 
14:41:34 <ivan> ... but I have never seen anybody using rdfa needing this
14:42:04 <ivan> ... using references in rdfa solves the issue
14:42:14 <ivan> ... you usually encapsulate that in a separate @about
14:42:23 <ivan> ... I do not see the advantage of that feature
14:42:41 <ivan> q+
14:42:49 <manu1> ack ivan
14:43:16 <lindstream> q+
14:43:39 <manu1> Ivan: We should do a write up of the last two issues and send them back to Jeni to see if she agrees with our findings.
14:44:27 <manu1> ack lindstream
14:44:32 <ivan> lindstream: I agree that a writeup would be good to explain
14:44:39 <ShaneM> q+ to ask about the itemref resolving differently from different parts of the document
14:44:45 <ivan> ... we should find out the real use cases and express those with rel/rev
14:45:00 <ivan> ... I have never seen this need in any kind of representation of data
14:45:13 <ivan> ... I cannot see any use case of switch vocab and use the same terms
14:45:24 <ivan> ... it would make no sense to me
14:45:47 <ivan> ... If there was a use case for which about should be extended to have multiple values, we should look at that instead
14:45:49 <manu1> ack shanem
14:45:49 <Zakim> ShaneM, you wanted to ask about the itemref resolving differently from different parts of the document
14:46:12 <ivan> ShaneM: with itemref if I refer to something from a different place it will be interpreted differently
14:46:25 <ivan> ivan: that is my understanding
14:46:31 <ivan> manu1: not mine...
14:47:13 <ivan> <s itemtype="URI1>... < itemref="#q"> </s>
14:47:23 <ivan> <s itemtype="URI2>... < itemref="#q"> </s>
14:47:42 <ivan> <sss id="q" itemprop="bla">....</sss>
14:49:02 <gkellogg> @itemref seems like microformat's include pattern
14:49:18 <manu1> That's because @itemref was inspired by Microformat's include pattern.
14:49:59 <manu1> ACTION: scor to check the @itemref functionality.
14:49:59 <trackbot> Sorry, couldn't find user - scor
14:50:00 <tomayac> http://www.xanthir.com/blog/b4570 has a use case which seems to make sense
14:51:12 <lindstream> q+
14:51:12 <ivan> tomayac: looking at the code in the box, if you have a table with information on something, they use the itemref to get the organization for the columns
14:52:04 <manu1> ack lindstream
14:52:14 <ivan> lindstream: from my quick read I am quite confident that @about would solve it
14:52:23 <ivan> ... it seems to solve the problem
14:52:41 <ivan> tomayac: probably using @about and explicit reference we should be able to solve the problem
14:53:04 <ivan> lindstream: it is a good example, though
14:53:32 <tomayac> thanks, lindstream ;-) just a random google finding though...
14:53:34 <Zakim> -scor
14:53:47 <Zakim> +scor
14:54:27 <lindstream> tomayac: random googling often yields gold ;)
14:54:51 <lindstream> ... rdfa lists?
14:55:03 <manu1> ACTION: Manu to respond to Jeni on ISSUE-105.
14:55:03 <trackbot> Created ACTION-92 - Respond to Jeni on ISSUE-105. [on Manu Sporny - due 2011-09-08].
14:55:24 <manu1> Topic: Publication timeline for 3rd LC of RDFa Core 1.1
14:55:43 <ivan> manu1: the sooner the better...
14:55:49 <ivan> ... we have a set of issues in the queue
14:55:59 <ivan> q+
14:56:13 <ivan> ... we would like a final document at the schema.org event
14:56:24 <manu1> ack ivan
14:58:04 <tomayac> @rev is deprecated in html5, shanem
14:58:12 <manu1> Ivan: We want a document that is stable again - we have xsd:string issue, link/meta is only really applicable to HTML+RDFa, @itemref is done, rdf:List is important, @src is important to discuss, Default profile needs to be done (should they be profiles or something else), 
14:59:28 <gkellogg> Verified with my distiller that two @itemrefs will generate properties with different URIs
14:59:29 <manu1> Ivan: We should be able to settle these in the coming 3 weeks - technically speaking, the document can be in a very good Editors Draft by the schema.org meeting time.
14:59:57 <manu1> Shane: We will create a date-spaced editors draft.
15:01:30 <gkellogg> q+
15:02:11 <ivan> gkellogg: it may be worth to add a note on the xsd:string that future rdf will change that feature
15:02:35 <manu1> ack gkellogg
15:02:35 <ShaneM> ack gkellogg
15:02:47 <Zakim> -scor
15:03:26 <Zakim> -tomayac
15:03:28 <Zakim> -manu1
# SPECIAL MARKER FOR CHATSYNC.  DO NOT EDIT THIS LINE OR BELOW.  SRCLINESUSED=00000265