Chatlog 2011-04-21

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

13:19:52 <RRSAgent> RRSAgent has joined #rdfa
13:19:52 <RRSAgent> logging to http://www.w3.org/2011/04/21-rdfa-irc
13:19:54 <trackbot> RRSAgent, make logs world
13:19:54 <Zakim> Zakim has joined #rdfa
13:19:56 <trackbot> Zakim, this will be 7332
13:19:56 <Zakim> ok, trackbot; I see SW_RDFa()10:00AM scheduled to start in 41 minutes
13:19:57 <trackbot> Meeting: RDF Web Applications Working Group Teleconference
13:19:57 <trackbot> Date: 21 April 2011
13:31:06 <MacTed> MacTed has joined #rdfa
13:35:23 <Steven> Steven has joined #rdfa
13:47:10 <manu1> Agenda: http://lists.w3.org/Archives/Public/public-rdfa-wg/2011Apr/0105.html
13:47:39 <manu1> Chair: Manu
13:48:16 <manu1> Present: Ivan, Ted, Steven, Nathan, Manu, Knud, Benjamin, Thomas
13:50:43 <Benjamin> Benjamin has joined #rdfa
13:58:59 <Knud> Knud has joined #rdfa
13:59:56 <Zakim> SW_RDFa()10:00AM has now started
14:00:03 <Zakim> +Knud
14:00:24 <Knud> zakim, mute me
14:00:24 <Zakim> sorry, Knud, muting is not permitted when only one person is present
14:00:48 <Zakim> +OpenLink_Software
14:01:00 <Zakim> +??P9
14:01:03 <MacTed> Zakim, OpenLink_Software is temporarily me
14:01:03 <Zakim> +MacTed; got it
14:01:11 <ivan> zakim, dial ivan-voip
14:01:11 <Zakim> ok, ivan; the call is being made
14:01:12 <Zakim> +Ivan
14:01:13 <MacTed> Zakim, mute me
14:01:13 <Zakim> MacTed should now be muted
14:01:26 <manu1> zakim, ??P9 is me
14:01:26 <Zakim> +manu1; got it
14:02:58 <Knud> zakim, mute me
14:02:58 <Zakim> Knud should now be muted
14:03:37 <Steven> zakim, dial steven-office
14:03:37 <Zakim> I am sorry, Steven; I do not know a number for steven-office
14:03:47 <Steven> zakim, dial steven-work
14:03:47 <Zakim> ok, Steven; the call is being made
14:03:48 <Zakim> +Steven
14:04:23 <Steven> zakim, who is here?
14:04:23 <Zakim> On the phone I see Knud (muted), MacTed (muted), manu1, Ivan, Steven
14:04:24 <Zakim> On IRC I see Knud, Benjamin, Steven, MacTed, Zakim, RRSAgent, ivan, danbri, webr3, manu1, manu, trackbot
14:05:38 <Zakim> +tomayac
14:06:35 <Zakim> -Knud
14:06:38 <tomayac> tomayac has joined #rdfa
14:06:57 <manu1> scribe: manu1
14:07:13 <Zakim> + +49.630.138.9.aaaa
14:07:14 <Zakim> +Knud
14:07:16 <manu1> Topic: F2F at TPAC
14:07:21 <Knud> zakim, mute me
14:07:21 <Zakim> Knud should now be muted
14:07:37 <Benjamin> zakim, I am aaaa
14:07:37 <Zakim> +Benjamin; got it
14:07:57 <manu1> 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 <tomayac> zakim, who is on the phone?
14:08:06 <Zakim> On the phone I see MacTed (muted), manu1, Ivan, Steven, tomayac, Benjamin, Knud (muted)
14:08:23 <manu1> Ivan: TPAC is the week of October 31st
14:08:44 <manu1> 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 <manu1> 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 <Knud> Ivan: in St. Clara, CA
14:09:18 <tomayac> +1 for ivan proposition!
14:09:21 <manu1> Ivan: Would be good to have some people there.
14:09:39 <manu1> Manu: Sounds like a good idea
14:09:51 <manu1> Ivan: I can make it
14:09:55 <manu1> Steven: I may be able to make it.
14:10:13 <Knud> I would love to, but find it unlikely that I'll have funding for it
14:10:18 <manu1> Tom: I think I'll be there.
14:10:32 <MacTed> Zakim, unmute me
14:10:32 <Zakim> MacTed should no longer be muted
14:11:03 <manu1> Ted: It's possible that I may be able to make it.
14:11:19 <Zakim> +??P31
14:11:22 <manu1> Ivan: We might also have the RDB2RDF WG having a meeting there as well.
14:11:24 <webr3> Zakim, i am ??p31
14:11:24 <Zakim> +webr3; got it
14:11:29 <MacTed> Zakim, mute me
14:11:30 <Zakim> MacTed should now be muted
14:11:32 <manu1> Ivan: RDF WG is still pending.
14:11:51 <manu1> Ivan: Registration deadline is April 30th - a little more than a week.
14:12:02 <manu1> Ivan: Maybe we can poll the group on e-mail and have a final decision.
14:12:43 <manu1> Manu: I think having 4-5 people there would be a good turnout.
14:13:59 <manu1> Manu: If we time it correctly, it would be right before we enter LC with the API docs.
14:14:13 <manu1> Topic: Update on changes to the RDF API
14:14:44 <Benjamin> http://www.w3.org/2010/02/rdfa/sources/rdf-api/Overview-src.html
14:15:06 <ivan> q+
14:15:20 <manu1> 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 <manu1> Nathan: Removed 'import from graph' - constraint on prefixes/terms as valid NCNames has been removed.
14:16:24 <manu1> 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 <manu1> 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 <manu1> 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 <manu1> 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 <manu1> 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 <webr3> there is the vocabulary with a property in it, "rdfa:term"
14:20:53 <manu1> 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 <manu1> Manu: We'd make the change across all documents.
14:21:44 <manu1> Ivan: This may be a painful change...
14:21:53 <Zakim> -Benjamin
14:22:40 <Zakim> +Benjamin
14:22:55 <manu1> Manu: Well, we haven't had the discussion yet.
14:22:59 <webr3> 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 <manu1> Ivan: I would prefer not to make the change at this time.
14:23:26 <manu1> Manu: Would you like the name to change from 'alias' back to 'term'.
14:23:43 <manu1> Nathan: That would be fine to change it back.
14:24:22 <manu1> 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 <manu1> 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 <manu1> 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 <manu1> q+
14:25:40 <manu1> ack ivan
14:25:51 <manu1> ack manu
14:25:55 <webr3> q+ to say unsure it even needs to be in the api, that's a layer above
14:26:31 <manu1> ack webr3
14:26:31 <Zakim> webr3, you wanted to say unsure it even needs to be in the api, that's a layer above
14:26:43 <manu1> Manu: I'm not sure if this is in scope for the RDF API... 
14:26:56 <tomayac> the lib is called sparql.js: http://thefigtrees.net/lee/sw/sparql.js
14:27:02 <ivan> -> http://thefigtrees.net/lee/sw/sparql.js Lee's liobrary
14:27:11 <manu1> 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 <manu1> Nathan: originally, parse() was left unconstrained - implementation detail on whether or not you allow remote graphs to be loaded.
14:28:03 <Benjamin> q+
14:28:13 <manu1> 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 <manu1> ack Benjamin
14:28:49 <manu1> 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 <manu1> Ivan: I think we should look at Lee's JavaScript and see what he did.
14:29:35 <webr3> 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 <manu1> Ivan: I'm a bit unclear if we could just provide an example library for doing SPARQL queries.
14:30:12 <tomayac> there's also spark by denny vrandecic et al: http://km.aifb.kit.edu/sites/spark/docs/
14:31:08 <manu1> Ivan: Do we have a query mechanism in RDF API?
14:31:12 <webr3> rdfa yes
14:31:15 <webr3> rdf no
14:31:20 <manu1> Nathan: You can reduce a set of triples down to a subset.
14:31:32 <manu1> Nathan: ... but there is no query() mechanism yet.
14:31:53 <manu1> Nathan: This document has changed to be a very core API - tailored toward library implementers.
14:32:25 <manu1> Nathan: The end-user APIs are up to the libraries themselves.
14:32:51 <manu1> Nathan: We allow others to innovate on top of the RDF API
14:33:10 <ivan> q+
14:33:20 <manu1> Nathan: We need to decide on a single viewpoint of where we are headed with the RDF API.
14:33:37 <manu1> Ivan: I agree w/ Nathan - the RDF API is the core stuff - that's the layer we're working with.
14:33:53 <manu1> Ivan: We have the RDFa API... there may be something in the middle that is missing.
14:34:07 <manu1> Ivan: Maybe Nathan is saying that we leave the stuff in the middle to the community - we don't design it.
14:34:10 <webr3> q+
14:34:27 <manu1> 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 <manu1> ack ivan
14:34:47 <manu1> 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 <Benjamin> q+ to discuss the possibility to carry triples in a Graph along multiple HTTP Requests
14:35:28 <manu1> 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 <manu1> ISSUE: Should the RDF API have a query() mechanism that is capable of loading remote documents.
14:35:46 <trackbot> 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 <manu1> ISSUE: Should the RDF API support SPARQL?
14:36:00 <trackbot> 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 <manu1> ack webr3
14:36:40 <manu1> 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 <manu1> Nathan: We may end up merging complex implementation stuff into the RDFa API - it might become a mess over time.
14:37:23 <manu1> Ivan: I fully agree
14:37:29 <manu1> ack Benjamin
14:37:29 <Zakim> Benjamin, you wanted to discuss the possibility to carry triples in a Graph along multiple HTTP Requests
14:37:41 <manu1> Benjamin: Yes, I see your point
14:38:00 <manu1> Benjamin: How do you carry triples as you go from page to page?
14:38:21 <webr3> shall I?
14:38:27 <manu1> Manu: Are we talking about a persistent triple store?
14:38:30 <manu1> Benjamin: Yes
14:38:50 <manu1> Manu: So having a set of triples that follows you from Google, to Facebook, to Twitter.
14:39:32 <manu1> 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 implementations.
14:39:44 <webr3> reference to old mail on topic: http://lists.w3.org/Archives/Public/public-rdfa-wg/2010Nov/0029.html
14:40:03 <manu1> 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 <manu1> Ivan: This is not something that the API has to define.
14:40:34 <Benjamin> q+
14:40:42 <webr3> q+ too :)
14:40:54 <manu1> Ivan: Clarification - the implementation could create a /type/ of store - persistent or in-memory.
14:41:15 <manu1> Benjamin: What if we make it specific - you can ask for a persistent store.
14:41:23 <manu1> ack Benjamin
14:41:28 <manu1> ack too
14:41:28 <Zakim> too, you wanted to say )
14:41:45 <manu1> Ivan: That makes the implementations much more complicated.
14:41:55 <manu1> Benjamin: Yes, but it's very useful.
14:41:59 <webr3> q+
14:42:55 <manu1> 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 <manu1> Nathan: We have multiple types of stores - persistent via IndexDB, named graph stores, etc. that can be implemented.
14:44:52 <manu1> 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 <manu1> Nathan: Persistent storage is out of scope for what we're doing.
14:46:20 <manu1> ISSUE: Should the RDF API support persistent storage?
14:46:20 <trackbot> 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 <webr3> optional ?
14:48:08 <webr3> ?
14:48:49 <webr3> yes its in
14:48:57 <webr3> triple = ( node node node )
14:49:00 <manu1> Nathan: There are a few bugs that I'd like to fix up.
14:49:05 <manu1> Nathan: before publication.
14:49:26 <manu1> Topic: RDF API Pure Graph Triples and Graph Literals
14:49:53 <webr3> is the topic: graph literal, or subjects as literals etc too?
14:51:12 <manu1> Manu: There are two issues: The first is that the RDF API allows literals in the subject and the predicate position - the API is generic and doesn't constrain graphs to the point that the RDF Concepts document does. The second is that we use the term "Graph Literal" when the RDF WG has had lots of conversations about what this term might be called and we do not want to seems as if we're making a decision before they figure out the proper name for this concept.
14:51:25 <webr3> see - http://jena.sourceforge.net/javadoc/com/hp/hpl/jena/graph/Triple.html
14:51:37 <manu1> Ivan: The point is that we have restrictions in RDF... Graph Literals are a very different thing.
14:51:57 <webr3> q+
14:52:13 <manu1> 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 <manu1> Ivan: I don't think we should go beyond RDF with this spec.
14:52:49 <manu1> Nathan: My main concern is that if we constrain the interface to match RDF, we will never have a compliant implementation.
14:52:59 <manu1> Nathan: I think most everybody will be more general with it.
14:53:30 <manu1> Ivan: RDFlib implemented what RDF requires... they do optimization w/ the literals.
14:55:30 <Benjamin> q+
14:55:35 <ivan> q+
14:55:39 <webr3> "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 interface?"
14:55:41 <webr3> ack webr3
14:55:50 <manu1> ack webr3
14:56:00 <manu1> Manu: There is no reason to constrain the RDF API.
14:56:06 <manu1> Manu: ... that is the model.
14:56:27 <manu1> 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 by just reading the WebIDL - it's very generic.
14:56:37 <webr3> q+ to mention a minor detail..
14:56:44 <ivan> ack Benjamin 
14:57:57 <manu1> q+ to describe "literal as predicate"
14:58:27 <manu1> Ivan: This is not clear that people want literals as predicates, not clear that people want a generic mechanism.
14:59:10 <manu1> 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 <manu1> Ivan: We are not doing this API work in isolation.
14:59:51 <manu1> Nathan: These were added after TimBL requested this generalized graph interface as well as Thomas Roessler
15:00:22 <manu1> 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 <manu1> ack webr3
15:00:34 <Zakim> webr3, you wanted to mention a minor detail..
15:00:38 <manu1> ack ivan
15:01:18 <webr3> 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 <webr3> 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 <webr3> s/make/made
15:02:09 <manu1> 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 <manu1> ...feedback. Or, we could remove it and put in an issue and a note.... we need feedback.
15:02:18 <manu1> Ivan: We should discuss this with RDF WG.
15:02:21 <manu1> q+ 
15:02:39 <manu1> Ivan: I don't know how I would explain in the RDF API document to have something that goes beyond RDF.
15:02:44 <manu1> ack manu
15:02:47 <Zakim> manu, you wanted to describe "literal as predicate" and to 
15:03:30 <webr3> 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 <webr3> s/GraphLiteral/TripleSet ?
15:05:48 <manu1> Manu: I would like to use this to trigger a discussion in the RDF community.
15:06:15 <webr3> q+
15:06:36 <Benjamin> q+
15:06:37 <manu1> 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 <manu1> ack webr3
15:07:09 <manu1> Nathan: Can we do a quick straw poll - who would object to generalized triples - who would object to GraphLiteral.
15:07:31 <manu1> ack Benjamin
15:07:57 <manu1> Benjamin: I think what matters is what we can accomplish w/ the API - we are discussing functionality w/o use cases.
15:07:59 <MacTed> +1
15:08:32 <MacTed> use cases drive features ("requirements").  features should not drive use cases.
15:09:21 <webr3> 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 <manu1> 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 <webr3> that won't happen though, we know it, for bc reasons
15:12:12 <manu1> Ivan: We need to have this discussion in the RDF WG. We have to be consistent.
15:12:25 <webr3> rdf won't change, out of charter, you told us that already
15:12:32 <webr3> so what's to discuss?
15:13:06 <MacTed> "graph identifier"?
15:13:28 <manu1> Ivan: This creates huge modelling issues if we allow literals as subjects/predicates.
15:13:31 <webr3> graoh identifier = name, not set of triples
15:13:40 <webr3> s/graoh/graph
15:14:55 <webr3> we had that constrain baked in to interfaces, rather than text
15:15:59 <manu1> Ivan: Today, there is a literal that could appear in the subject position...
15:16:03 <manu1> Benjamin: We need to talk about this in the text.
15:16:33 <webr3> manu: i agree
15:17:11 <webr3> okay
15:17:12 <manu1> Ivan: Let's put this into the document and review the document.
15:17:16 <Benjamin> ok
15:18:07 <webr3> k
15:18:30 <webr3> can i call it "TripleSet" or something?
15:18:49 <Zakim> -Benjamin
15:18:56 <manu1> 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 <webr3> "GBox" ?
15:19:34 <manu1> Ivan: Let's try to find other terms for Graph stuff...
15:19:44 <manu1> Manu: I'm fine w/ GBox - wait for RDF WG to finalize the terms.
15:19:55 <webr3> "TripleSet"?
15:20:24 <MacTed> links to terminology definitions are wonderful things
15:20:36 <manu1> 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 <manu1> Ivan: We should say that we'll use whatever terminology that the RDF WG will want to use.
15:21:21 <manu1> Nathan: As long as we say that it is a set of triples...
15:22:06 <webr3> ACTION nathan to generate fpwd draft of RDF API following minutes of today
15:22:06 <trackbot> Created ACTION-74 - Generate fpwd draft of RDF API following minutes of today [on Nathan Rixham - due 2011-04-28].
15:22:20 <webr3> cheers
15:22:27 <Zakim> -Steven
15:22:28 <MacTed> ciao
15:22:29 <Zakim> -MacTed
15:22:30 <Zakim> -tomayac
15:22:30 <Zakim> -Ivan
15:22:31 <Zakim> -webr3
15:22:31 <Zakim> -manu1
15:22:33 <Knud> Knud has left #rdfa
15:22:35 <Zakim> -Knud
15:22:36 <Zakim> SW_RDFa()10:00AM has ended
15:22:38 <Zakim> Attendees were Knud, MacTed, Ivan, manu1, Steven, tomayac, +49.630.138.9.aaaa, Benjamin, webr3
# SPECIAL MARKER FOR CHATSYNC.  DO NOT EDIT THIS LINE OR BELOW.  SRCLINESUSED=00000285