13:19:52 RRSAgent has joined #rdfa 13:19:52 logging to http://www.w3.org/2011/04/21-rdfa-irc 13:19:54 RRSAgent, make logs world 13:19:54 Zakim has joined #rdfa 13:19:56 Zakim, this will be 7332 13:19:56 ok, trackbot; I see SW_RDFa()10:00AM scheduled to start in 41 minutes 13:19:57 Meeting: RDF Web Applications Working Group Teleconference 13:19:57 Date: 21 April 2011 13:31:06 MacTed has joined #rdfa 13:35:23 Steven has joined #rdfa 13:47:10 Agenda: http://lists.w3.org/Archives/Public/public-rdfa-wg/2011Apr/0105.html 13:47:39 Chair: Manu 13:48:16 Present: Ivan, Ted, Steven, Nathan, Manu 13:50:16 manu? 13:50:43 Benjamin has joined #rdfa 13:54:47 we should spend some time on a possible f2f at tpac... 13:54:55 i mean: on the call 13:58:59 Knud has joined #rdfa 13:59:56 SW_RDFa()10:00AM has now started 14:00:03 +Knud 14:00:24 zakim, mute me 14:00:24 sorry, Knud, muting is not permitted when only one person is present 14:00:48 +OpenLink_Software 14:01:00 +??P9 14:01:03 Zakim, OpenLink_Software is temporarily me 14:01:03 +MacTed; got it 14:01:11 zakim, dial ivan-voip 14:01:11 ok, ivan; the call is being made 14:01:12 +Ivan 14:01:13 Zakim, mute me 14:01:13 MacTed should now be muted 14:01:17 speakerphones often do 14:01:26 zakim, ??P9 is me 14:01:26 +manu1; got it 14:02:58 zakim, mute me 14:02:58 Knud should now be muted 14:03:37 zakim, dial steven-office 14:03:37 I am sorry, Steven; I do not know a number for steven-office 14:03:47 zakim, dial steven-work 14:03:47 ok, Steven; the call is being made 14:03:48 +Steven 14:04:23 zakim, who is here? 14:04:23 On the phone I see Knud (muted), MacTed (muted), manu1, Ivan, Steven 14:04:24 On IRC I see Knud, Benjamin, Steven, MacTed, Zakim, RRSAgent, ivan, danbri, webr3, manu1, manu, trackbot 14:05:38 +tomayac 14:06:20 oh this would be fine 14:06:35 -Knud 14:06:38 tomayac has joined #rdfa 14:06:57 scribe: manu1 14:07:13 + +49.630.138.9.aaaa 14:07:14 +Knud 14:07:16 Topic: F2F at TPAC 14:07:21 zakim, mute me 14:07:21 Knud should now be muted 14:07:21 thanks knut 14:07:37 zakim, I am aaaa 14:07:37 +Benjamin; got it 14:07:57 Ivan: The charter doesn't say that we need to have a F2F, but I wonder if we could do one at TPAC? 14:08:06 zakim, who is on the phone? 14:08:06 On the phone I see MacTed (muted), manu1, Ivan, Steven, tomayac, Benjamin, Knud (muted) 14:08:23 Ivan: TPAC is the week of October 31st 14:08:44 Ivan: We have lots of F2F meetings there - it would be nice because there will be lots of HTML5 and WebApps folks there. 14:09:02 Ivan: I think it would be a great opportunity, perhaps the only one, where this group could have discussion w/ those folks. 14:09:07 Ivan: in St. Clara, CA 14:09:18 +1 for ivan proposition! 14:09:21 Ivan: Would be good to have some people there. 14:09:39 Manu: Sounds like a good idea 14:09:51 Ivan: I can make it 14:09:55 Steven: I may be able to make it. 14:10:13 I would love to, but find it unlikely that I'll have funding for it 14:10:18 Tom: I think I'll be there. 14:10:32 Zakim, unmute me 14:10:32 MacTed should no longer be muted 14:11:03 Ted: It's possible that I may be able to make it. 14:11:19 +??P31 14:11:22 Ivan: We might also have the RDB2RDF WG having a meeting there as well. 14:11:24 Zakim, i am ??p31 14:11:24 +webr3; got it 14:11:29 Zakim, mute me 14:11:30 MacTed should now be muted 14:11:32 Ivan: RDF WG is still pending. 14:11:51 Ivan: Registration deadline is April 30th - a little more than a week. 14:12:02 Ivan: Maybe we can poll the group on e-mail and have a final decision. 14:12:43 Manu: I think having 4-5 people there would be a good turnout. 14:13:59 Manu: If we time it correctly, it would be right before we enter LC with the API docs. 14:14:13 Topic: Update on changes to the RDF API 14:14:44 http://www.w3.org/2010/02/rdfa/sources/rdf-api/Overview-src.html 14:15:06 q+ 14:15:20 Nathan: I've made the changes I sent to the group - changed 'term' to be 'alias' - removed the 'base' functionality from profile 14:15:59 Nathan: Removed 'import from graph' - constraint on prefixes/terms as valid NCNames has been removed. 14:16:24 Nathan: a prefix is a string that doesn't have any whitespace - so is a term - you can distinguish between term/prefix - CURIEs have a colon in them 14:17:29 Benjamin: I changed the document - extended the abstract, wrote an introduction, similar to the RDFa API - I added a "design considerations" section, changed the concept stack a bit - described some goals of the API 14:18:19 Benjamin: Need to talk w/ Nathan a bit on this - wrote examples and use cases - wrote 3 examples - described them using text - I wanted to make a JavaScript code example for the first example, but for the last two, I was missing functionality 14:18:44 Benjamin: The persistence of a graph within a single HTTP request - don't know if you can take a graph w/ you across multiple HTTP requests. 14:19:16 Benjamin: At the moment, we cannot access remote SPARQL endpoints via "DESCRIBE" or "CONSTRUCT" queries - seems like something we'd want to have in there. 14:20:27 there's is the vocabulary with a property in it, "rdfa:term" 14:20:53 Ivan: This is a minor comment - read the minutes on the issue of 'term' - don't have an issue calling it 'alias' in the API - do we want to have this terminology the same across all documents? 14:21:04 Manu: We'd make the change across all documents. 14:21:44 Ivan: This may be a painful change... 14:21:53 -Benjamin 14:22:40 +Benjamin 14:22:55 Manu: Well, we haven't had the discussion yet. 14:22:59 that's my understanding too - generally it was "put it in the API document and we can discuss for core, if there's an issue then raise it on RDF API to turn it back to "term" 14:23:03 Ivan: I would prefer not to make the change at this time. 14:23:26 Manu: Would you like the name to change from 'alias' back to 'term'. 14:23:43 Nathan: That would be fine to change it back. 14:24:22 Ivan: I wanted to understand Benjamin's comment - remote SPARQL stuff is a URI - from a parser point of view - it's a URI that will return RDF/XML that the parser will parse - what's the issue here? 14:24:50 Benjamin: It's not complicated to implement - but we should have a convenience method to the API - a method that performs a SPARQL query and returns a graph in our implementation. 14:25:36 Ivan: Ah ok - it may be worth noting that LeeF has a small JavaScript library that is an interface to a SPARQL endpoint - you give a SPARQL query and it'll do all of the machinations to create a SPARQL query URL. 14:25:38 q+ 14:25:40 ack ivan 14:25:51 ack manu 14:25:55 q+ to say unsure it even needs to be in the api, that's a layer above 14:26:31 ack webr3 14:26:31 webr3, you wanted to say unsure it even needs to be in the api, that's a layer above 14:26:43 Manu: I'm not sure if this is in scope for the RDF API... 14:26:56 the lib is called sparql.js: http://thefigtrees.net/lee/sw/sparql.js 14:27:02 -> http://thefigtrees.net/lee/sw/sparql.js Lee's liobrary 14:27:11 Nathan: It seems that whatever that is returned back is RDF in some form, so it's the job of a parser to parse it. 14:27:43 Nathan: originally, parse() was left unconstrained - implementation detail on whether or not you allow remote graphs to be loaded. 14:28:03 q+ 14:28:13 Nathan: There is no reason why you couldn't have a SPARQL parser - the first parameter could be a SPARQL query or a URI. 14:28:19 ack Benjamin 14:28:49 Benjamin: I think an experienced developer would end up needing a SPARQL convenience mechanism... it's small, it would be good to have it. 14:29:05 Ivan: I think we should look at Lee's JavaScript and see what he did. 14:29:35 this is a scoping thing we need to discuss then, because it went from a nice friendly linked data api, down to two apis (rdfa and rdf) and then to a very core api focussed on rdf library developers, and on interop between - not an end user api 14:30:06 Ivan: I'm a bit unclear if we could just provide an example library for doing SPARQL queries. 14:30:12 there's also spark by denny vrandecic et al: http://km.aifb.kit.edu/sites/spark/docs/ 14:30:44 ivan: no 14:30:52 rdfa yes 14:30:55 rdf no 14:31:08 Ivan: Do we have a query mechanism in RDF API? 14:31:20 Nathan: You can reduce a set of triples down to a subset. 14:31:32 Nathan: ... but there is no query() mechanism yet. 14:31:53 Nathan: This document has changed to be a very core API - tailored toward library implementers. 14:32:25 Nathan: The end-user APIs are up to the libraries themselves. 14:32:51 Nathan: We allow others to innovate on top of the RDF API 14:33:10 q+ 14:33:20 Nathan: We need to decide on a single viewpoint of where we are headed with the RDF API. 14:33:37 Ivan: I agree w/ Nathan - the RDF API is the core stuff - that's the layer we're working with. 14:33:53 Ivan: We have the RDFa API... there may be something in the middle that is missing. 14:34:07 Ivan: Maybe Nathan is saying that we leave the stuff in the middle to the community - we don't design it. 14:34:10 q+ 14:34:27 Ivan: Perhaps we want to standardize it if we find something useful... I don't think we should do SPARQL query interface. 14:34:29 ack ivan 14:34:47 Ivan: I think people will build the SPARQL query interfaces - I'd like to take stuff like Projections out of the RDFa API 14:35:28 q+ to discuss the possibility to carry triples in a Graph along multiple HTTP Requests 14:35:28 Ivan: until now, I didn't think about SPARQL and queries... let's postpone the issue until we have a more thorough discussion about what exactly the core RDF API is doing. 14:35:46 ISSUE: Should the RDF API have a query() mechanism that is capable of loading remote documents. 14:35:46 Created ISSUE-91 - Should the RDF API have a query() mechanism that is capable of loading remote documents. ; please complete additional details at http://www.w3.org/2010/02/rdfa/track/issues/91/edit . 14:35:59 ISSUE: Should the RDF API support SPARQL? 14:36:00 Created ISSUE-92 - Should the RDF API support SPARQL? ; please complete additional details at http://www.w3.org/2010/02/rdfa/track/issues/92/edit . 14:36:06 ack webr3 14:36:40 Nathan: I agree w/ Ivan - we need 3 different layers of API - if we do anything else in the middle, it may pollute the RDFa API 14:37:19 Nathan: We may end up merging complex implementation stuff into the RDFa API - it might become a mess over time. 14:37:23 Ivan: I fully agree 14:37:29 ack Benjamin 14:37:29 Benjamin, you wanted to discuss the possibility to carry triples in a Graph along multiple HTTP Requests 14:37:41 Benjamin: Yes, I see your point 14:38:00 Benjamin: How do you carry triples as you go from page to page? 14:38:21 shall I? 14:38:27 Manu: Are we talking about a persistent triple store? 14:38:30 Benjamin: Yes 14:38:50 Manu: So having a set of triples that follows you from Google, to Facebook, to Twitter. 14:39:32 Ivan: There is an abstraction of a store - implementations may have different stores - by default you get an in-memory store, which can be piggybacked on top of a SQLite database... in Jena, that's up to the impelemtnations. 14:39:44 reference to old mail on topic: http://lists.w3.org/Archives/Public/public-rdfa-wg/2010Nov/0029.html 14:40:03 Ivan: It seems that this is up to the RDF Store... as far as the API goes, it may be what we want to define - the implementation may define something on top of the RDF API 14:40:11 Ivan: This is not something that the API has to define. 14:40:34 q+ 14:40:42 q+ too :) 14:40:54 Ivan: Clarification - the implementation could create a /type/ of store - persistent or in-memory. 14:41:15 Benjamin: What if we make it specific - you can ask for a persistent store. 14:41:23 ack Benjamin 14:41:28 ack too 14:41:28 too, you wanted to say ) 14:41:45 Ivan: That makes the implementations much more complicated. 14:41:55 Benjamin: Yes, but it's very useful. 14:41:59 q+ 14:42:55 Manu: You wouldn't be able to do a full implementation of the RDF API in pure JavaScript if we required persistence. 14:44:02 Nathan: We have multiple types of stores - persistent via IndexDB, named graph stores, etc. that can be implemented. 14:44:52 Nathan: Many different people w/ do it in many different ways... any interface that we define will not cover all of the use cases out there 14:45:01 Nathan: Persistent storage is out of scope for what we're doing. 14:46:20 ISSUE: Should the RDF API support persistent storage? 14:46:20 Created ISSUE-93 - Should the RDF API support persistent storage? ; please complete additional details at http://www.w3.org/2010/02/rdfa/track/issues/93/edit . 14:48:06 optional ? 14:48:08 ? 14:48:49 yes its in 14:48:57 triple = ( node node node ) 14:49:00 Nathan: There are a few bugs that I'd like to fix up. 14:49:05 Nathan: before publication. 14:49:26 Topic: RDF API Graph Literals 14:49:53 is the topic: graph literal, or subjects as literals etc too? 14:51:12 Manu: The issue is SCRIBE_CLEANUP 14:51:25 see: http://jena.sourceforge.net/javadoc/com/hp/hpl/jena/graph/Triple.html 14:51:37 Ivan: The point is that we have restrictions in RDF... Graph Literals are a very different thing. 14:51:57 q+ 14:52:13 Ivan: I'm uneasy - this is an API on what the RDF standard is... it allows /more/ than RDF - it's a little strange. 14:52:31 Ivan: I don't think we should go beyond RDF with this spec. 14:52:49 Nathan: My main concern is that if we constrain the interface to match RDF, we will never have a compliant implementation. 14:52:59 Nathan: I think most everybody will be more general with it. 14:53:30 Ivan: RDFlib implemented what RDF requires... they do optimization w/ the literals. 14:55:30 q+ 14:55:35 q+ 14:55:39 "why do you want to force me not to have a literal in the subject position, in my own code, in my library, behind the itnerface?" 14:55:41 ack webr3 14:55:50 ack webr3 14:56:00 Manu: There is no reason to constrain the RDF API. 14:56:06 Manu: ... that is the model. 14:56:27 Benjamin: If we are going to generalize, we should talk about why we're doing it... It was very difficult to get into the API description. 14:56:37 q+ to mention a minor detail.. 14:56:44 ack Benjamin 14:57:57 q+ to describe "literal as predicate" 14:58:27 Ivan: This is not clear that people want literals as predicates, not clear that people want a generic mechanism. 14:59:10 Ivan: It's up to implementations to implement in a more generic way, the RDF API should constrain that - what we define is not an RDF API if we allow generic mechanisms like this - it's RDF+ 14:59:28 Ivan: We are not doing this API work in isolation. 14:59:51 Nathan: These were added after TimBL requested this generalized graph interface as well as Thomas Roessler 15:00:22 Nathan: When we discussed this, we decided to keep it in the API as long as possible to see if there was major push back from the community - if there was major pushback, we can take it out... if not, we leave it in. 15:00:34 ack webr3 15:00:34 webr3, you wanted to mention a minor detail.. 15:00:38 ack ivan 15:01:18 ahh yes, "meaning" we're not working with meaning we're working with triples etc, meaning is added via interpretation, so who cares what it means in RDF. 15:01:40 and.. if RDF or RDF2 is make more generic in the future, why shouldn't this API be compatible? (and n3 compat) 15:01:47 s/make/made 15:02:09 Ivan: So, I would certainly be opposed to have these documents be published and have these additional things be a part of a document as a part of a simple matter of fact... what we could do as a compromise is we could publish in present state and put big issue markers in the document stating whether or not we should go beyond RDF or not - something that the WG is not consensus on - we need... 15:02:11 ...feedback. Or, we could remove it and put in an issue and a note.... we need feedback. 15:02:18 Ivan: We should discuss this with RDF WG. 15:02:21 q+ 15:02:39 Ivan: I don't know how I would explain in the RDF API document to have something that goes beyond RDF. 15:02:44 ack manu 15:02:47 manu, you wanted to describe "literal as predicate" and to 15:03:30 Ivan: pfps also said the same, but didn't object just said "can you change it so it doesn't say interface for the "RDF concepts", change that intro sentence and he'd be happy "interfaces for working with RDF" or such like 15:04:58 s/GraphLiteral/TripleSet ? 15:05:48 Manu: I would like to use this to trigger a discussion in the RDF community. 15:06:15 q+ 15:06:36 q+ 15:06:37 Ivan: I don't think we should go there - let's not provoke another group by coming out with a draft that coins the term "GraphLiteral" 15:06:40 ack webr3 15:07:09 Nathan: Can we do a quick straw poll - who would object to generalized triples - who would object to GraphLiteral. 15:07:31 ack Benjamin 15:07:57 Benjamin: I think what matters is what we can accomplish w/ the API - we are discussing functionality w/o use cases. 15:07:59 +1 15:08:32 use cases drive features ("requirements"). features should not drive use cases. 15:09:21 primary use cases were the same interfaces being able to be used by reasoners and sparql implementations and for n3 compat (because you know, one lib will handle all this) 15:11:52 Ivan: The problem I have is that we're doing more than RDF. It is very important that the RECs that W3C produces are consistent with one another. 15:12:08 that won't happen though, we know it, for bc reasons 15:12:12 Ivan: We need to have this discussion in the RDF WG. We have to be consistent. 15:12:25 rdf won't change, out of charter, you told us that already 15:12:32 so what's to discuss? 15:13:06 "graph identifier"? 15:13:28 Ivan: This creates huge modelling issues if we allow literals as subjects/predicates. 15:13:31 graoh identifier = name, not set of triples 15:13:40 s/graoh/graph 15:14:55 we had that constrain baked in to interfaces, rather than text 15:15:59 Ivan: Today, there is a literal that could appear in the subject position... 15:16:03 Benjamin: We need to talk about this in the text. 15:16:33 manu: i agree 15:17:11 okay 15:17:12 Ivan: Let's put this into the document and review the document. 15:17:16 ok 15:18:07 k 15:18:30 can i call it "TripleSet" or something? 15:18:49 -Benjamin 15:18:56 Manu: Ok, Nathan will make the change to constrain the RDF API to not allow literals as subjects, but keep the IDL generic. 15:19:23 "GBox" ? 15:19:34 Ivan: Let's try to find other terms for Graph stuff... 15:19:44 Manu: I'm fine w/ GBox - wait for RDF WG to finalize the terms. 15:19:55 "TripleSet"? 15:20:24 links to terminology definitions are wonderful things 15:20:36 Ivan: Don't put in loaded terms... you should put in a note in a document making it clear that the terminology used here is under heavy discussion in the RDF WG. 15:20:57 Ivan: We should say that we'll use whatever terminology that the RDF WG will want to use. 15:21:21 Nathan: As long as we say that it is a set of triples... 15:22:06 ACTION nathan to generate fpwd draft of RDF API following minutes of today 15:22:06 Created ACTION-74 - Generate fpwd draft of RDF API following minutes of today [on Nathan Rixham - due 2011-04-28]. 15:22:20 cheers 15:22:27 -Steven 15:22:28 ciao 15:22:29 -MacTed 15:22:30 -tomayac 15:22:30 -Ivan 15:22:31 -webr3 15:22:31 -manu1 15:22:33 Knud has left #rdfa 15:22:35 -Knud 15:22:36 SW_RDFa()10:00AM has ended 15:22:38 Attendees were Knud, MacTed, Ivan, manu1, Steven, tomayac, +49.630.138.9.aaaa, Benjamin, webr3 15:34:08 tinkster has joined #rdfa 16:07:44 rrsagent,bye 16:07:44 I see no action items