<trackbot> Date: 23 March 2011

<sandro> ww, I don't see what you mean by write operations. I don't see either side of the A3 communication thinking in triples.

<davidwood> Scribe: Jeremy Carroll

aabb is me

<davidwood> Scribenick: JeremyCarroll

<zwu2> how do we do that?

<davidwood> Zakim instructions: http://www.w3.org/2001/12/zakim-irc-bot.html

<zwu2> who is on the phone?

<mischat> zakime, unmute me

<ww> 

<ww> zakim +??P17 is me

<cygri> pfps 73394#

<davidwood> Zakim code: 73394

<JeremyScribe> David: welcome everyone - focus on JSON

<ww> zakim +??P43 is me

<davidwood> PROPOSED to accept the minutes of the 16 March telecon:

<pfps> Minutes are acceptable, even with minor issues

<davidwood> http://www.w3.org/2011/rdf-wg/meeting/2011-03-16

<manu1> +1 to accept the minutes

<tomayac> +1 to accept

<JFB> +1 to accept

<JeremyScribe> Minutes accepted

<JeremyScribe> No action items to review

<JeremyScribe> pending items

<JeremyScribe> Action-4 is open, another use case has been added

<JeremyScribe> Suggested to close it since the use case has been added

<JeremyScribe> Closed. Richard did the action

<sandro> action-6?

<trackbot> ACTION-6 -- Patrick Hayes to provide use case for graphs -- due 2011-03-02 -- OPEN

<trackbot> http://www.w3.org/2011/rdf-wg/track/actions/6

<JeremyScribe> Action-6: pat hayes

<trackbot> ACTION-6 Provide use case for graphs notes added

<davidwood> Jeremy: Danbri did the action

<danbri> (foaf use case action should be linked from the action tracker)

<JeremyScribe> ACTION-19:

<JeremyScribe> Richard has started this but is still working on it

<PatHayes> Its OK for me, pfps.

<JeremyScribe> This action is time consuming because it involves a lot of software

<JeremyScribe> His goal is to list import formats and to explore output formats

<zwu2> To save you some time, Oracle can take all kinds of input format, when going through Jena APIs or Sesame APIs

<JeremyScribe> ACTION-20: TomSteiner is trying to get side by side comparison

<trackbot> ACTION-20 Create and start to populate a wiki area of demo graphs with how they each look in each json proposal. notes added

<tomayac> http://www.w3.org/2011/rdf-wg/wiki/TF-JSON#JSON_Serializations_By_Example

<zwu2> sounds good

<PatHayes> LOL

<JeremyScribe> this action is still open, input data is being gathered

<JeremyScribe> test cases will be added to Wiki

<JeremyScribe> Action item review complete

<trackbot> Sorry, couldn't find user - item

<JeremyScribe> Please respond to f2f proposal as to whether you are attending or not

<JeremyScribe> Hotels in Amsterdam filling up on Thursday

<Souri_> Is attending the F2F remotely from Boston area an option?

<JeremyScribe> Focus of meeting on JSON, if spare time some spare topics still to discuss

<manu1> http://lists.w3.org/Archives/Public/public-rdf-wg/2011Mar/0521.html

<JeremyScribe> Manu: presents where we are at

<JeremyScribe> Manu: TF telecon report back

<JeremyScribe> Manu: TF agrees that a JSON format would be a good thing

<JeremyScribe> Manu: sense of urgency was low-to-moderate

<AndyS> --> JSON format for SPARQL results

<JeremyScribe> Manu: half group were concerned about govt and enterprise

<JeremyScribe> Manu: half more concerned abotu independent developers

<JeremyScribe> Manu: we need to make sure that we keep as many people on board as possible

<JeremyScribe> Pat: why do motivations matter?

<JeremyScribe> Manu: there are technical consequences given motivations, e.g. APIs vs publishing formats

<zwu2> is it possible to build adapters/bridges between two different RDF/JSON serialization formats?

<webr3> everything is possible :)

<JeremyScribe> Manu: doamin of interest, and use cases, and technical solutions are all interrelated

<zwu2> is there an efficient way then?

<AndyS> zwu2 - RDF?

<JeremyScribe> Manu: if we do not have enough people interested in a topic then we will not be able to pursue such a technical soln

<zwu2> RDF/JSON, andy

<JeremyScribe> Manu: there was discussion concerning round tripping

<JeremyScribe> Manu: round tripping - can data that is GET ted then be POST ed back

<JeremyScribe> Manu: without data loss

<JeremyScribe> Manu: it seemed clear when people spoke what they wanted, but not clear that there was consensus in TF

<JeremyScribe> Manu: issue of premature standardization

<JeremyScribe> Manu: this is a strong concern, unclear whether some JSON solutions will work,

<ww> JSON-UL?

<JeremyScribe> Manu: there is general unfamiliarity with some formats, cf: ACTION-20

<Souri_> Is attending the first F2F remotely from Boston area an option? I remember that Ivan had said that it is not. Just trying to confirm.

<JeremyScribe> Manu: many motivations behind different formats are currently not well understood by many members of group

<JeremyScribe> David: can we use use cases to understand different people's preferences

<cygri> davidwood++

<JeremyScribe> David: this would help in seeing what work can be resourced properly, and possibly help in reaching consensus

<webr3> ACTION: nathan to group json use cases on wiki [recorded in http://www.w3.org/2011/03/23-rdf-wg-minutes.html#action01]

<trackbot> Created ACTION-22 - Group json use cases on wiki [on Nathan Rixham - due 2011-03-30].

<JeremyScribe> Richard: agrees that grouping use cases will help

<JeremyScribe> David (as Talis rep, not chair): there is no internal consensus about this issue, but there are strong opinions

<JeremyScribe> David (...): 1 opinion is that an API is needed, otherwise format is doomed

<webr3> David, can you clarify what you mean by "API" (api as in tooling for consumers) or "API" as in linked-data-api ?

<JeremyScribe> David (...): 2 opinion is triple format is crucial

<JeremyScribe> David (...): as rep it is hard to map different people's opinions onto use cases

<JeremyScribe> David (as chair): Guus prefers a bottom up approach

<JeremyScribe> David: Guus wants minimal approach, adding features with motivation

<webr3> David, next q - by "starting point" did you mean a simple object then add, or a simple triple, then add?

<davidwood> web3r: yes

<sandro> url for RDF API spec?

<davidwood> web3r: oops :) I meant a simple object.

<JeremyScribe> Manu: we would like to see more people on APIs in JavaScript or Python

<webr3> Sandro, http://www.w3.org/2010/02/rdfa/sources/rdf-api/

<webr3> davidwood, then +1, i agree

<davidwood> sandro: The LOD API spec is at http://www.w3.org/2010/02/rdfa/sources/rdf-api/

<ww> yes. http://bibliographica.org/

<Zakim> sandro, you wanted to talk about the matrix

<JeremyScribe> Manu: who is shipping a product requiring JSON technologies

<JeremyScribe> Sandro: I have a hard time understanding use cases - mix of abstraction and concrete

<JeremyScribe> Sandro: I like the matrix

<manu1> http://www.w3.org/2011/rdf-wg/wiki/JSON_User_Segments

<JeremyScribe> Sandro: we are trying to get data from producer to consumer, this gives a square on matrix

<JeremyScribe> Sandro: each square sort of corresponds to a use case

<sandro> http://www.w3.org/2011/rdf-wg/wiki/JSON_User_Segments

<ww> mischat: the data store is rdf. the user interface is json/resty thing and web developers that know about rdf are hard to come by. so need to translate json i/o to rdf i/o

<JeremyScribe> some consumers want RDF, some don't

<JeremyScribe> some consumers are happy to use a library, others are not happy to use a library

<ww> which we've already done in an application-specific way but it would be nice to have a more standard/consistent way

<JeremyScribe> sandro: if people are nto rpepared to use library, then encoding has to be really simple

<JeremyScribe> sandro: this is where Tallis' rpoducts are at - simple encoding

<ww> example: our franken-simpleish-json: http://bnb.bibliographica.org/entry/GB5105626.json

<JeremyScribe> David: is there a difference between librarys or APIs

<JeremyScribe> Sandro: no

<Zakim> JeremyScribe, you wanted to answer JSON

<webr3> ww, why does it flip between qnames/curies and simple keys? (type / "dc:isPartOf")

<ww> webr3: the algorithm is, is there a property on the python object that is explicitly modelled and we know a priori in an application-specific way what predicate it is? then just use the property name

<ww> 2. do we have a known prefix we can use? use that (e.g. curie)

<ww> 3. use <uri>

<webr3> ww, do you see (2) as being important or would 1+3 be acceptable?

<Zakim> manu1, you wanted to discuss really simple encoding.

<JeremyScribe> Jeremy: in TQ's client server protocol, issues to do with client side caching and temporal semantics - to make it neutral to programmer as to whether a triple is locally cached or involves server round trip

<ww> webr3: let's follow up on the list

<tomayac> (really hard time understanding manu. anyone else? bandwidth issue?)

<JeremyScribe> Manu: of the people represented here, there do not seem to be actual business requirements

<webr3> likewise, I have business use-cases for a few clients

<tomayac> (dialed in the us bridge. redialing. we had the same issue in the media fragments wg this morning)

<tomayac> (to ivan lol, don't have a prob w/ manu neither ;-) only hearing him)

<Zakim> sandro, you wanted to suggest we each briefly put forward one quick use case

<JeremyScribe> sandro: should we discuss use cases for rest of telecon?

<JeremyScribe> david: do you want to categorize them?

<JeremyScribe> sandro: only if easy

<sandro> sandro: please queue yourself to talk about the json use case you care about the most

<JeremyScribe> ?: second case, people who have simple non-RDF objects in NoSQL db but they want to expose these as RDF

<davidwood> I'll ask Nathan to scribe his own use case when he is done

<JeremyScribe> Nathan: first case was that they wanted tripled based data to be exposed as simple objects without RDF

<Zakim> manu1, you wanted to discuss PaySwarm

<JeremyScribe> Manu: we are working on universal payment standard

<mischat> http://payswarm.com/

<JeremyScribe> Manu: want a decentralized system that avoids reentering of financial data

<JeremyScribe> Manu: core technology is RDFa in HTML

<JeremyScribe> Manu: data is stored either in triple store or document store

<JeremyScribe> Manu: assumption is HTML+RDFa not a triple store

<JeremyScribe> Manu: lots of URIs for identifying thins

<JeremyScribe> Manu: need someway to express data which web developers are comfortable with

<JeremyScribe> Manu: turtle etc are way outside comfort zone of developers discussed

<JeremyScribe> Manu: needs to be as easy as twitter or facebook API

<JeremyScribe> Manu: API can be converted into triples, but can be used directly

<sandro> manu: We want to provide an API where people who care about triples can get them, but others can use the API directly, where it just looks like json.

<sandro> (very clear at the end, Manu, thanks.)

<JeremyScribe> Richard: we have RDF data in a SPARQL store

<JeremyScribe> Richard: we want to build one or more apps that use this data

<JeremyScribe> Richard: we want to develop these apps in JavaScript because it makes development process simpler

<JeremyScribe> Richard: we currently do simple select queries with JSON results format from SPARQL

<JeremyScribe> Richard: processing this is straightforward

<sandro> cygri:We want something the encodes the output of SPARQL CONSTRUCT or DESCRIBE in a simple and predictable way for the Javascript developer who is already familiar with RDF. They know SPARQL and can think in triples.

<webr3> Nathan: I have two distinct groups of publishers (1) those who have rdf-triples behind the scenes (2) those who have non-rdf objects behind the scenes | both of those groups want to target both non-rdf developers, and rdf-developers. This creates two core needs: (a) a way to give rdf-triples as simple-objects to non-rdf developers (b) a way to give simple-objects as rdf to rdf-developers

<webr3> Nathan: distinct from that I see two other cases (c) dumping rdf as json as a leightweight triple format (d) sparql (which I see as orthogonal, is sparql engine on client or server?)

<JeremyScribe> Richard: but we also want to use things like DESCRIBE or CONSTRUCT

<JeremyScribe> Richard: but these do not give a JSON result

<sandro> cygri: This is most interesting if you don't really want to use a consumer library; if library is okay, then use existing syntax. It's nice to just code away on the raw json, though.

<JeremyScribe> I don't think it was me

<JeremyScribe> Richard: want simple or predictable result format for DESCRIBE and CONSTRUCT

<JeremyScribe> Richard: we don't really want a library, because if library is OK then there is no problem to sovle (library can do whatever magic is needed)

<ivan> The requirements of Manu and Richard are not very dissimilar...

<davidwood> JeremyScribe, no it wasn't you

<JeremyScribe> Richard: related problem is posting data back to SPARQL store

<manu1> I wouldn't say that Ivan - not clear at the moment...

<JeremyScribe> e.g. with HTTP PUT

<sandro> cygri: also, good to post back to store. json serialization for simple encoding of RDF graph.

<sandro> (great, cygri)

<PatHayes> yup

<JeremyScribe> ww: has use cases with end users in web browswers annotating data

<JeremyScribe> ww: the end users actions are mediated by web developers

<JeremyScribe> ww: the web developers neither know nor want to know about RDF

<JeremyScribe> ww: but these developers need to mediate between a triple store and the end users

<sandro> ww: The developers don't seem to know much about modeling in RDF, and don't want to, but the modeling in the back is RDF.

<JeremyScribe> ww: mechanisms involve HTTP PUT/POST/GET and JSON but not sure how

<manu1> People might want to look at this as a complex example: http://purl.org/payswarm#Contract

<JeremyScribe> zwu: I understand why web developers do not want RDF/XML, but why not turtle

<sandro> zwu2: Why would developers really not want to get near Turtle. It's really simple.

<davidwood> It may interest some to see how James Leigh and I roundtrip RDF to and from a browser: http://callimachusproject.org

<sandro> manu: They say they already know json, and don't see why they need something else.

<JeremyScribe> manu: dev say we already know JSON, why should we learn more?

<sandro> manu: They just don't see the problem that json doesn't address.

<JeremyScribe> manu: web developers use json to read and write data and accomplish their tasks involving linked data like tasks

<ww> somewhat harshly, i've been told that it is not reasonable to expect developers to "go back to school" and learn about something new, and rdf seems pretty different

<sandro> manu: and you don't need much more. you just uris, and folks already do that a lot. most of that can be done on the server side. "Why are you making me learn something new, when that's not really required."

<JeremyScribe> manu: why are you making me learn something new ...

<JeremyScribe> zwu: RDF is not a huge deal

<JeremyScribe> manu: but the learning curves are huge

<JeremyScribe> +1 to manu

<ivan> +1 to manu

<cygri> +10 to manu

<ww> +100 to manu

<JeremyScribe> David: agrees with manu

<mischat> fwiw we built the whole of http://foafbuilder.qdos.com/builder/ which is very ajaxie, or "ajar-ie" in timbl speak. Our model in the MVC was RDF, storage a triplestore. and like above RDF to and from a browser

<webr3> they have a full stack including progamming languages all setup around working with classes and objects - they just aren't setup to handle triples and graphs (who is??!)

<sandro> manu: The RDF concepts are really not something that are easy to pick up and learn.

<JeremyScribe> many: strong agreement with manu

<manu1> +1 to David

<ivan> +1 to David

<JeremyScribe> David: we want web developers to use this technology, rather than web dev want to use these

<cygri> food for thought: http://www.google.com/trends?q=json%2Crdf&ctab=0&geo=all&date=all&sort=0

<sandro> davidwood: We want web developers to adopt this technology, more than they want to adopt it. We can't put stumbling blocks in their way.

<ivan> zhe, do not underestimate the weight of a familiar syntax

<davidwood> cygri: very relevant!

<JeremyScribe> manu: I don't thinkw eb dev grok some of the advanced topics to do with linked data

<ww> uri as a global *property/predicate* identifier is difficult - you can't write that in most OO type languages

<pfps> isn't JSON at least formally "open"

<manu1> +1 to Jeremy

<AndyS> AndyS supports cygri example (roughly)

<JeremyScribe> Jeremy: uri as global identifier as opposed to local scoped id is one key RDF concept

<sandro> cygri, http://www.google.com/trends?q=data%2C+love&ctab=0&geo=all&date=all&sort=1

<JeremyScribe> Jeremy: open schema of RDFS ratehr than fully specified app schema is a second

<JeremyScribe> Jeremy: both are advacned and difficult

<mischat> I thought we are supposed to be standardising common practices ....

<PatHayes> The other frightening thing about RDF is, if one probes the 'buzz' for insight, one finds a lot of worry and confusion and debate and so on, rather than a bunch of nice easy tutorials.

<sandro> indeed, PatHayes, it's not a pretty picture.

<AndyS> We did not finish JSON UCs

<PatHayes> So maybe we should make it our business to paint some better pictures :-)

<zwu2> bye

<JeremyScribe> yes

<JeremyScribe> Gavin will scribe next week

<JeremyScribe> meeting adjourned

<davidwood> Thanks, Jeremy!

<JeremyScribe> rssagent, draft minutes

This is scribe.perl Revision: 1.135  of Date: 2009/03/02 03:52:20  
Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/

Guessing input format: RRSAgent_Text_Format (score 1.00)

Found Scribe: Jeremy Carroll
Found ScribeNick: JeremyCarroll
WARNING: No scribe lines found matching ScribeNick pattern: <JeremyCarroll> ...

WARNING: 2 scribe lines found (out of 490 total lines.)
Are you sure you specified a correct ScribeNick?


WARNING: No "Topic:" lines found.

Default Present: Tony, David, Sandro, LeeF, OlivierCorby, +1.415.369.aabb, JeremyCarroll, AndyS, manu1, mischat_, tomayac_, PatH, Ivan, JFB, zwu2, FabGandon, +1.603.897.aaee, cygri, Peter_Patel-Schneider, AlexHall, webr3, Souri_, ww, Ronald, AxelPolleres
Present: Tony David Sandro LeeF OlivierCorby +1.415.369.aabb JeremyCarroll AndyS manu1 mischat_ tomayac_ PatH Ivan JFB zwu2 FabGandon +1.603.897.aaee cygri Peter_Patel-Schneider AlexHall webr3 Souri_ ww Ronald AxelPolleres
Found Date: 23 Mar 2011
Guessing minutes URL: http://www.w3.org/2011/03/23-rdf-wg-minutes.html
People with action items: nathan

WARNING: Input appears to use implicit continuation lines.
You may need the "-implicitContinuations" option.


WARNING: No "Topic: ..." lines found!  
Resulting HTML may have an empty (invalid) <ol>...</ol>.

Explanation: "Topic: ..." lines are used to indicate the start of 
new discussion topics or agenda items, such as:
<dbooth> Topic: Review of Amy's report