Chatlog 2010-11-04

From RDFa Working Group Wiki
Jump to: navigation, search

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>
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>
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 -
10:17:00 <manu> Knud Möller: +1 -
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:
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>
10:30:00 <manu>
10:36:00 <manu> Topic: ISSUE-52: Lightweight DataStore aligned with ECMAScript
10:36:00 <manu>
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>
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