Warning:
This wiki has been archived and is now read-only.
Chatlog 2010-11-04
From RDFa Working Group Wiki
See CommonScribe Control Panel, original RRSAgent log and preview nicely formatted version.
10:02:00 <ivan> Present: Manu, Shane, Ivan, Nathan, Benjamin 10:02:00 <ivan> scribenick: ivan 10:03:00 <ivan> Scribe: Ivan 10:03:00 <manu> Regrets: Knud, MarkB, Steven 10:04:00 <manu> Topic: XHTML+RDFa Last Call 10:04:00 <manu> http://www.w3.org/2010/02/rdfa/drafts/2010/ED-xhtml-rdfa-20101101/ 10:05:00 <ivan> manu: shane, are there any issues that have not been addressed? 10:05:00 <ivan> ShaneM: mark had a concern in section 3 of the document 10:05:00 <ivan> ... there are bulleted 'modifications' or additions to the processing rules 10:06:00 <ivan> ... the last two he thinks needs additional clarification 10:06:00 <ivan> ... I think they are already covered in step 7, so it is not necessary 10:06:00 <ivan> manu: are there test cases 10:06:00 <ivan> ShaneM: these are not new changes 10:06:00 <ivan> ... so we should 10:07:00 <ivan> manu: this particular issue does not have anything to do with the <html> element, as you say 10:07:00 <ivan> .. anyone having a deep concern about not putting more words here? 10:07:00 <ivan> ... it would be editorial 10:07:00 <ivan> ShaneM: not sure 10:08:00 <ivan> manu: we are not changing the way the spec works, we just clarify what is happening, no design changes 10:08:00 <ivan> ... do you agree 10:08:00 <ivan> ShaneM: I cannot imagine what change we would make and that would change anyone's processor 10:08:00 <ivan> ... in this sense you are right 10:08:00 <ShaneM> http://www.w3.org/2010/02/rdfa/sources/rdfa-core/Overview-src.html#sequence 10:09:00 <ivan> ... but the text in rdfa core, section 6 I think it explicitly deals with typeof 10:09:00 <ivan> ... mark was saying that we need to say where in step 7 these additional processing rules come into play 10:09:00 <ivan> ... but I think it is very clear 10:11:00 <manu> Sequence, step #6: If no URI is provided by a resource attribute, then the first match from the following rules will apply: 10:11:00 <manu> if @typeof is present, then new subject is set to be a newly created bnode. 10:11:00 <manu> XHTML+RDFa 1.1 says: In section 7.5, processing step 6, if no URI is provided by a resource attribute (e.g., @about, @href, @resource, or @src), then first check to see if the element is the head or body element. If it is, then act as if there is an empty @about present, and process it according to the rule for @about. 10:11:00 <ivan> manu: it seems to be perfectly fine 10:12:00 <ivan> ... I agree with you shane there is no issue here 10:12:00 <ivan> ShaneM: that was the only issue that I know of 10:13:00 <ivan> manu: there was an issue in which order we process? 10:13:00 <ivan> .. only <base> carries over to the body 10:13:00 <ivan> ... from head 10:14:00 <ivan> manu: any issues? any reason why we should not take XHTML+RDFa 1.1 to last call? 10:15:00 <manu> PROPOSAL: Promote XHTML+RDFa 1.1 to Last Call with a publication date of November 9th, 2010. 10:16:00 <ivan> Ivan: +1 10:16:00 <manu> +1 10:16:00 <nathan> +1 10:16:00 <Benjamin> +1 10:16:00 <ShaneM> +1 10:16:00 <manu> Mark Birbeck: +1 - http://lists.w3.org/Archives/Public/public-rdfa-wg/2010Nov/0026.html 10:17:00 <manu> Knud Möller: +1 - http://lists.w3.org/Archives/Public/public-rdfa-wg/2010Nov/0027.html 10:17:00 <ivan> RESOLVED: Promote XHTML+RDFa 1.1 to Last Call with a publication date of November 9th, 2010. 10:18:00 <ivan> Topic: HTML+RDFa Last Call plans 10:18:00 <ivan> manu: for plan for HTML5+RDFa: the plan is to clean up the bugs on dec 5, and the idea is to put the documents to LC in early spring 10:18:00 <ivan> ... the biggest issue we have is that people that are trying to pull us into the fight into the HTML discussion so that RDFa processors should generate accessibilty triples 10:18:00 <ShaneM> q+ to ask about PFWG 10:19:00 <manu> ack shaneM 10:19:00 <Zakim> ShaneM, you wanted to ask about PFWG 10:19:00 <ivan> that would mean that html5+rdfa processors would generate different thigns than before 10:19:00 <ivan> ShaneM: what are you talking about with the pfwg hat on? 10:21:00 <manu> Open bugs for HTML+RDFa: http://www.w3.org/Bugs/Public/show_bug.cgi?id=10970 http://www.w3.org/Bugs/Public/show_bug.cgi?id=11169 10:22:00 <ivan> ShaneM: there was an agreement not to follow that up? 10:22:00 <ivan> ... on 4th october he said he would not follow that up 10:22:00 <ivan> manu: ... in the rdfa group. But not in the html wg 10:23:00 <ivan> ... and he is pushing on accessibility discussion 10:23:00 <ivan> ... he was very involved, and he tried to pull the rdfa wg into this discussion 10:23:00 <ivan> ... he thinks we should generate triples for <cite> is that the microdata spec supports it 10:23:00 <ivan> manu: but feature parity with microdata is not a goal for us 10:25:00 <ShaneM> ACTION: Shane get a statement from the PFWG on HTML+RDFa issues 11169 and 10970 (triples for @longdesc and @cite) 10:25:00 <trackbot> Created ACTION-39 - Get a statement from the PFWG on HTML+RDFa issues 11169 and 10970 (triples for @longdesc and @cite) [on Shane McCarron - due 2010-11-11]. 10:25:00 <manu> zakim, who is making noise? 10:25:00 <Zakim> manu, listening for 10 seconds I heard sound from the following: ??P19 (50%), ??P22 (19%), Ivan (62%) 10:26:00 <manu> zakim, who is on the call? 10:26:00 <Zakim> On the phone I see no one 10:26:00 <manu> zakim, mute ??P19 10:26:00 <Zakim> sorry, manu, I do not know which phone connection belongs to ??P19 10:27:00 <manu> Ivan: The point that we have to make clear is that the current RDFa Core 1.1 doesn't have any formal mechanism to extend RDFa Core w/ additional elements/attributes could/should be supported. 10:27:00 <manu> Ivan: We don't have a formal mechanism where we can extend the attributes processed by RDFa Core - for example @datetime in HTML5. 10:28:00 <manu> Ivan: We don't have anything to extend the processing steps - we can't just add these items for different languages easily. 10:28:00 <manu> Manu: We can't put it in the HTML+RDFa spec because you can't detect the difference between XHTML1.1 and HTML5 in a way that is not ambiguous 100% of the time. Having different processors do different things also makes implementation much more difficult. I think the key point to make is that RDFa doesn't stop anyone from generating these triples, but we shouldn't mandate this in the spec as it complicates implementations. 10:29:00 <ShaneM> FYI - what we said w.r.t. our own internal version of issue 10970 was: 10:29:00 <ShaneM> I believe that the discussion was aware that this work might be done > in XHTML+RDFa. In the end, I agree with the working group that it > would be inappropriate at this time to try to introduce any > processing rules for @cite and @longdesc in any flavor of RDFa. My > recollection of the meeting is that this opinion was agreed by the > majority of the people present. 10:29:00 <manu> http://www.w3.org/Bugs/Public/show_bug.cgi?id=7670 10:30:00 <manu> http://www.w3.org/html/wg/tracker/issues/120 10:36:00 <manu> Topic: ISSUE-52: Lightweight DataStore aligned with ECMAScript 10:36:00 <manu> http://www.w3.org/2010/02/rdfa/track/issues/52 10:36:00 <ivan> manu: this is our biggest issue 10:36:00 <ivan> ... but mark is not on the call today:-( 10:37:00 <ivan> ... there is a lot of stuff in it 10:37:00 <ivan> ... there was some discussion on graph, store, data store, etc 10:37:00 <ivan> ... a lot of the decision on the interface depends on that 10:37:00 <ivan> ... question is whether we have a graph plus data store or not 10:38:00 <ivan> nathan: if we do not have a graph in the api 10:38:00 <ivan> ... so that is completely in the api at all 10:38:00 <ivan> ... we have a data store which is not clear whether it has one, or several set of triples 10:38:00 <ivan> ... so it was not fully defined 10:38:00 <ivan> ... when i implemented and i realized this 10:39:00 <ivan> ... want to realign it to have a clear set of triples 10:39:00 <ivan> ... the datastore interface is more an array a triples 10:39:00 <ivan> ... and we came up that datastore is just a graph 10:40:00 <ivan> ... mark said that he had the idea was raised but was pushed back 10:40:00 <manu> q+ to discuss complexity for developers. 10:40:00 <manu> ack manu 10:40:00 <Zakim> manu, you wanted to discuss complexity for developers. 10:41:00 <ivan> manu: the gut reaction i had was this is getting more an more complicated to developers 10:41:00 <ivan> .... whatever we create should be simple for js developers 10:41:00 <ivan> ... but i want to make sure that the most common use case can be written down properly 10:41:00 <ivan> q+ 10:41:00 <ivan> ... and that is a danger 10:42:00 <ivan> ... it is not clear what a js developer would use this interface 10:42:00 <ivan> .. when a make a query, do they path a graph, a datastore, would they realize the difference between the two? 10:42:00 <manu> ack ivan 10:43:00 <manu> Ivan: In RDFlib - there are only graphs. 10:43:00 <manu> Ivan: I do operations on the graph - that is in the Python world - I don't understand the necessity of a DataStore. 10:43:00 <manu> Ivan: We have graphs or stores, why do we need both? 10:43:00 <manu> q+ to discuss named graphs. 10:44:00 <nathan> q+ to addres points 10:44:00 <manu> ack manu 10:44:00 <Zakim> manu, you wanted to discuss named graphs. 10:44:00 <ivan> manu: one of the reason is that having a concept the named graph 10:44:00 <ivan> q+ 10:44:00 <manu> ack webr 10:44:00 <Zakim> webr, you wanted to addres points 10:44:00 <manu> q+ webr to address points 10:45:00 <manu> ack ivan 10:45:00 <manu> Ivan: We have separate graphs, the first is the processing graph, the other one is something else. 10:45:00 <manu> ack webr 10:45:00 <Zakim> webr, you wanted to address points 10:45:00 <manu> q+ to discuss named graphs a bit more 10:45:00 <ivan> nathan: for the complexity 10:46:00 <ivan> ... this interface proposed is the same as an array in js, we can call it a graph, but it is the same 10:46:00 <ivan> ... we need some more methods, but it is a a js array 10:46:00 <ivan> ... it is familiar and normal for js programmer 10:46:00 <ivan> ... it is also easy to implement it 10:46:00 <ivan> ... you have to proxy things to an array 10:46:00 <ivan> ... from that aspect it is simpler and familiar 10:47:00 <ivan> ... the difference between the two: a datastore is where we store the graphs 10:47:00 <ivan> ... that is pretty much a datastore 10:47:00 <ivan> ... and if you have a datastore, we need a way to represent a graph 10:47:00 <ivan> ... we need a form of a graph 10:48:00 <ivan> ... finally...when you store a graph you pass a name to it, and you get the named graph 10:48:00 <ivan> ... that is essentially the role of a datastore 10:49:00 <ivan> ... and there is no concept of a named graph in the datastore right now 10:49:00 <manu> ack manu 10:49:00 <Zakim> manu, you wanted to discuss named graphs a bit more 10:49:00 <ivan> manu: you did clarify the named graph issue 10:49:00 <ivan> ... the rdfa wg has to decide is how to decide on named graphs 10:49:00 <ivan> q+ 10:49:00 <ivan> ... we might want to work on that 10:50:00 <nathan> q+ to make distinction between "RDFa API" and "RDF TripleStore API" 10:50:00 <ivan> ... we already the concept of a processor graph and we could formalize it in the api 10:50:00 <manu> ack ivan 10:50:00 <manu> Ivan: I disagree 10:51:00 <manu> Ivan: The RDFa Working Group does not have in its charter to do anything w/ Named Graphs - we don't even know what Named Graphs mean. There are ideas flying around in the community, but we don't know what the consensus is. 10:52:00 <manu> Ivan: There will probably be an RDF WG, they will have to decide what to do w/ Named Graphs, but that is going to take much longer than the charter of this WG. 10:52:00 <manu> Ivan: We should not push of LC for RDFa API for named graphs - that was the formal comment. 10:52:00 <manu> Ivan: In practice, we should provide enough extensibility that would allow the named graph stuff in the future. 10:53:00 <manu> Ivan: We have to deliver layer 1 and possibly layer 2 - RDFa API... 10:53:00 <manu> Ivan: but named graphs may be a layer 3 issue 10:53:00 <manu> Ivan: Doing Named Graphs is not in our charter -- formal. 10:53:00 <manu> ack webr 10:53:00 <Zakim> webr, you wanted to make distinction between "RDFa API" and "RDF TripleStore API" 10:53:00 <ivan> nathan: i agree with what ivan said 10:54:00 <ivan> ... with an rdfa document and the dom you do not need a store with multiple graphs 10:54:00 <ivan> ... what we need is a simple rdf graphs 10:54:00 <ivan> ... you can get many of those, merge them, you can deal with them 10:55:00 <ivan> ... what we do not have is to have multiple graphs with names etc, that is a matter of the rdf level and is not rdfa level 10:55:00 <manu> q+ to say that we don't have to name the graphs. 10:55:00 <manu> ack manu 10:55:00 <Zakim> manu, you wanted to say that we don't have to name the graphs. 10:55:00 <ivan> manu: part of me agrees with you 10:56:00 <ivan> ... we can have a concept of a graph, and we can put it in a datastore 10:56:00 <ivan> ... but that could mean a merge it, so we loose the provenance information 10:56:00 <ivan> ... we try to balance it 10:56:00 <ivan> ... ivan is right, if we do a named graph then we are creating a precedence 10:56:00 <Benjamin> q+ to ask if multiple stores can exist in the scope of a single document 10:57:00 <manu> ack Benjamin 10:57:00 <Zakim> Benjamin, you wanted to ask if multiple stores can exist in the scope of a single document 10:57:00 <ivan> ... then we can a problem if, for example, a rdf group says that it has to have a uri as a name, we have problems 10:57:00 <ivan> Benjamin: can we have multiple stores in a document? 10:57:00 <ivan> ... is it possible to handle them? 10:57:00 <ivan> .. i think it is 10:58:00 <ivan> nathan: currently we need a distinction between a graph and a store 10:58:00 <ivan> ... you can have multiple contexts, documents... 10:58:00 <ivan> ... if we define in a some way that we can have multiple datastores 10:58:00 <manu> q+ to ask Nathan to create DataStore and RDFGraph IDL 10:58:00 <ivan> ... but generally it is possible 10:59:00 <ivan> ... we have to think about different environments, because people want it 10:59:00 <ivan> ... we cannot do that with only one store and one databse 10:59:00 <ivan> ... one other thing 10:59:00 <ivan> ... there is a sparql consideration there, which raised the FROM thing 10:59:00 <ivan> ... we have to specify what the FROM is 10:59:00 <manu> ack manu 10:59:00 <Zakim> manu, you wanted to ask Nathan to create DataStore and RDFGraph IDL 11:00:00 <ivan> manu: it is difficult for me to imagine what exactly you have in mind 11:01:00 <ivan> nathan: we definitely need a graph, and many people will need a store 11:01:00 <ivan> ... but a store is so common that we can as well standardize it 11:01:00 <ivan> ... there conceptually two distinct things 11:01:00 <ivan> q+ 11:01:00 <manu> ack ivan 11:02:00 <ivan> manu: can you write the interfaces down so that we can discuss them next week 11:02:00 <manu> q+ to end the telecon 11:04:00 <nathan> q+ to clarify minor detail 11:04:00 <manu> ack manu 11:04:00 <Zakim> manu, you wanted to end the telecon 11:04:00 <ivan> --- adjurned 11:04:00 <manu> ack webr 11:04:00 <Zakim> webr, you wanted to clarify minor detail 11:13:00 <manu> http://www.w3.org/TR/rdfa-core/#accessing-the-processor-graph 11:16:00 <ShaneM> The point I raised was that the RDFa API needs to at the very least allow access to the processor graph and the default graph (and the combined graph?) 11:22:00 <ivan> zakim, drop me 11:22:00 <Zakim> sorry, ivan, I do not see a party named 'ivan' 11:22:00 <Zakim> SW_RDFa()10:00AM has ended 11:22:00 <Zakim> Attendees were # SPECIAL MARKER FOR CHATSYNC. DO NOT EDIT THIS LINE OR BELOW. SRCLINESUSED=00000192