SV_MEETING_TITLE -- 21 Mar 2011

<scribe> Scribe: Manu

<scribe> scribenick: manu1

<scribe> Agenda: http://lists.w3.org/Archives/Public/public-rdf-wg/2011Mar/0500.html

Market Segments

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

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

Manu: Let's talk about what we'd like this stuff to do for the communities

Sandro: I was getting lost, so I put that JSON USer segments bit together
... It became more clear for me by thinking about what people would be willing to do by publishing their JSON
... There are discrete levels, but the idea of the spectrum is pretty clear (communities)
... as for the data consumers, I asked whether or not they want anything to do with RDF.

<LeeF> which level is "RDF publishers, willing to publish in JSON"? 7?

<tomayac_> (have to change phones. will be right back. sorry)

Sandro: We need to ensure that we don't bug the people that are just using JSON today
... all the way up to Group C - who want to use a library/API

<AndyS> LeeF: +1 -- I attempted to answer that in my weekend email.

Sandro: Is level 3, 4 and 5 in scope? Need to discuss that.

<LeeF> AndyS, will check your mail, thanks

Sandro: Don't need to decide the in-scope bit.

<tomayac_> (and back)

AndyS: I found this diagram very helpful, no numbers in boxes, but it occured to me that there is a dual-diagram?
... There may be other ways of looking at this - existing JSON publishers into RDF - will people w/ RDF want to provide it in a convenient way to JSON-style applications.

<LeeF> AndyS's email++

Sandro: yes, that makes sense... maybe we can add that to the diagram

Manu: What would you like to see happen in the next 2-3 years?

<LeeF> "really interesting" == bad working group topic? :)

<SteveH> +1 :)

Sandro: Hard to tell at this point, interested in the green box

<sandro> webr3, press zero and ask the operator to add you.

<sandro> AndyS: with the greenish box, any technical pubs need some degree of proof/evidence. I'd like to see the evidence that it addresses them.

<sandro> +1 Andy

AndyS: The thing about the green-ish box - technical publications need proof/evidence behind them, attempting to address particular classes - close but not right prevents anything else from happening in that space.
... Of the three cases, I'm particularly motivated by presenting RDF web applications via JSON...

<sandro> andy: I'm particular motivated by presenting RDF info through JSON to RDF webapps.

<sandro> andy: ... but I'm not sure how important that is.

<AndyS> andy: ... RDF serialization may not be important.

AndyS: Turtle is closer to what I'd like...
... Talis' format has elements of both.
... That's talking about RDF serialization... but we may want to support on a lossy format?
... Exporting data from RDF to JSON, but taking data in published RDF and giving it to JSON applications.

Sandro: RDF through JSON?

<sandro> AndyS: an output format, need not round trip, but easier to read in json. "rdf in json" maybe. "rdf export in json" apps not 1st class RDF apps.

AndyS: It doesn't make the JSON applications first class RDF applications.
... Data Access JSON?

Manu: What's the target market?

<sandro> manu: Andy, which apps and communities?

AndyS: Government data - data from different sources and doing mash-ups

<sandro> AndyS: eg uk govt data mashups

AndyS: Combining government reference data and mashing/correlating - govt spending with school results.

SteveH: I've got two agendas - we work internally w/ RDF, but provide an API to our business parters in XML/JSON
... It would be interesting to directly expose our RDF, but businesses are moving very slowly toward that.

<sandro> SteveH: as a company that works exclusively in RDF, but provides APIs to our partners (json and xml), it would be nice to expose the RDF in a nice form to our partners

SteveH: Deep but growing concern that this is going to turn into RDF/XML again
... Doing something very slightly wrong could set back this area for quite some time.

<sandro> ... plus I'm worried about repeating some of the mistakes of RDF/XML. Doing something very-slightly-wrong could set back the field for a long time.

SteveH: We're interested in supporting financial industry/credit agencies, etc.
... Not really a field where web services are common - technologically backwards industry.
... JSON-LD at first glance looked applicable, but then it started to look like an eyesore.

<sandro> SteveH: Annotations scattered through the data rendered it unreadable.

SteveH: In principle you think that you can do RDF/XML, but it doesn't work out that way.

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

LeeF: I outlined our interest in that e-mail
... We work in an RDF world, we work in RDF serializations - we work in triples

<sandro> LeeF: We work in an RDF world, but when we serve up RDF data to web apps, we use a json serializaton. We have a mild interest in a std in this area.

<AndyS> Andy's attempt to do the dual to Sandro's User Segmentation: http://lists.w3.org/Archives/Public/public-rdf-wg/2011Mar/0501.html

LeeF: Having a standard in this area would be great - we could interoperate well... but not a priority for us... just one step along that path, we don't have a particular need or interest in the JSON developer friendly way of reading standard JSON - but not a focus for us.
... We are interested in JSON for RDF - we're going to apply libraries to it, and shouldn't care about the serialization standard.
... Enterprise web developers - large companies using APIs to read data from endpoints - energy, financial services.

Ivan: The motivation for the charter... there are a large group of WebApps devs that ignore RDF
... Even in cases where they'd be better off with RDF
... All the people working in the social web XGs, they have walled gardens, any application that tries to merge the data would be better off using RDF
... but the kind of feedback that we get, RDF is too complicated, it's messy, etc. - it doesn't work for Web Apps folks. They have a point.
... What one would hope is that by having some sort of JSON view of RDF data, that might be good enough for many developers to use Linked Open Data.
... My feeling if I look at Sandro's matrix, for those people, the kind of JTriples approach (RDF/JSON) would not work for them.
... Not saying those serializations would not be useful, but it's the same issues that they've been complaining about.

<Zakim> SteveH, you wanted to ask Ivan about round-tripping

SteveH: Given your use case, I would think that you'd want to produce and consume data in the JSON syntax.
... Are you thinking just consuming or producing and consuming?

Ivan: Round-tripping would be good, but for many apps, it's not the case.
... You want to read and mash-up as a consumer... but no clear opinion on that

<Zakim> AndyS, you wanted to ask if the original data is RDF or other format?

AndyS: Is this where the original data is in RDF?

Ivan: Not necessarily.

AndyS: Where does the RDF come in, then?

Ivan: Some of the data is in RDF, but some of it isn't, what happens if I want to combine it?

Thomas: Looking at Sandro's matrix... our WG should focus on the right-ish, lower-ish 1/3rd to 1/2 of it

<AndyS> Ivan: desire is combining data from different sources (/me hope that's the right summary)

Thomas: Don't need the need or feasibility for Twitter to use what we suggest. Make one format to rule the world... don't think that this is what we should do.

<ivan> s/is it/it is/

Thomas: The really easy win woudl be to convince DBPedia, Freebase, etc to use one custom format.
... If you look at what we use today - they all use different publishing formats... the lower-right-ish corner of the matrix
... What would be interesting is providing RDF goggles, but don't entirely understand whether it would be generalizable.
... One-off for each and every data provider... don't know if it would be globally useful to have data goggles. Maybe provide a roadmap for data providers telling them how they could do this.

<sandro> ( webr3, is "rdf goggles" the green box? )

Thomas: People that are already committed in thinking about the triple way, use the JSON format to express that data - that's what I'd like... like the object-based approach, maps better to the way JSON people think.
... Not really worried about the billion triples stuff... no real need for JSON triples, they say use N-Triples, don't need yet another exchange format for simple triples..

<webr3> ( sandro, originally I was using the term to mean something more like JSON-Schema crossed with GRDDL for JSON, an external map which had rules to transform json objects in to rdf)

Thomas: If there is a need, we can come up with a format for simple triples in JSON - we need an object based approach, getting namespaces right, prefixes right... string literals vs. URIs, many details
... We need to get those details right, microsyntaxes, deeply nested objects, etc.
... Endless discussions sometimes, but hope it is worth is.
... Would like Drupal, Wordpress folks to adopt this stuff... a common serializatin format for their data... you can use atom, but would be nicer to use JSON as the API.
... Also see a need for a lightweight feed for shopping sites - lots of individual items that they need to publish somewhere.

Nathan: I work in a few different spaces, different viewpoints on these competing needs.
... For folks that are invested in RDF - I see a strong need in 6B (Sandro's graph) - SPARQL results being standardized - good to have a single syntax across the wire, between SPARQL, between RDF systems, JSON incredibly easy and fast to parse.
... Node.js doesn't have nice XML support - custom parsers for TURTLE, speed is noticable... JSON is fast.
... The other side is working w/ lots of developers - enterprise to open source
... Explaining RDF to many of them - takeaway is that they like the follow-your-nose side of things, like shared schema, crawling
... Key-value stores and JSON stores - NoSQL movement at the backend - working w/ raw objects all the time

<sandro> webr3: people like RDF, but really just fall back to the bits they like: (1) follow your nose, (2) shared schema, (3) kv stores / nosql

Nathan: Then they see the serializations, and then they giv eup on it - need a constrained RDF, simple datatypes - adding in date and adding in URI
... Those are the needs that I see - 6b and level 3, 4, and 5 groups - as long as we do one of them, I'd be happy, I'd like to do both

Ivan: I think it's perfectly fine for many of those apps - whatever serialization we do, it is lossy - so lossy serializations would be fine for many of these groups.

Nathan: Where most of these people are not using RDF stores or triple stores - many are heavily invested in NoSQL stores, column databases, etc.
... They're moving away from RDBMS to object stores - data is not in RDF - but they would like to provide it as RDF.
... They can understand/import other peoples data...

<tomayac_> +1 for keeping in mind the nosql community and the way these people think!

Nathan: The whole round-trippable side of things I don't see as important - you can pull in some objects, you can produce some objects, but doesn't have to be RDF.

Sandro: See an argument that we don't see round-tripping, leaving out expressibilility - whatever we leave out, someone will need it

AndyS: It seems like it's not a technical issue - right?

<webr3> agree w/ sandro, re blank nodes, it'd be simple to just leave out blank node identifiers and keep blank nodes (anonymous nested objects)

AndyS: If they saw a restricted mechainsm, they may have a different reaction. This may be why TURTLE is liked over RDF/XML.

Sandro: The problem here is one of hit with the firehose when they wanted a glass of water.
... Google RDF - you're not going to get anything useful

Thomas: One of the things we should do is read through the direction on json.org and make sure to understand where the serialization comes from
... We need to think the JavaScript way - weak typing, etc.
... You can do strong typing, but you shouldn't enforce it.

<tomayac_> i meant 2.0 and 2 dont make a diff, not "2" and 2.

<tomayac_> as in "this slap in your face hurts me more than you" ;-)

<webr3> manu: read write data also very important moving forwards

<sandro> I hear manu aiming at Level 4.

Sandro: I think you're characterising level 4

Manu: If you can't follow-your-nose, you can get a default context from another website.

AndyS: GRDDL hasn't taken off, we need to reflect on why

SteveH: So, I'm skeptical that you can take something like any RDF and serialize it into JSON-LD that anyone would want to consume.

<sandro> SteveH: I'm skeptical that you can serialize typical RDF into JSON-LD that anyone would want to consume.

SteveH: Serializing into TURTLE is pretty hard - into JSON would be really, really challenging

<sandro> +1 skeptical

SteveH: The risk is that we create a serialization that's theoretically possible, but it may be too ugly to use.

Nathan: I think we need two serializations - take RDF as JSON, and another constrained one for bigger folks like Facebook, Twitter.
... merging the two might be doing RDF/XML all over again.

AndyS: I'm not worried about entire RDF serialization into JSON
... if you're going to do that, parse N-Triples
... I don't think it would do any harm to translate RDF into JSON completely

<SteveH> +1 to AndyS, I've heard the "that's fine but X is not good for us" argument hundreds of times

<LeeF> +1 to AndyS, of course

AndyS: The lossy RDF serialization - you have RDF and you want to give it to JSON apps
... Lossy translation of RDF down to JSON - you have RDF and you want to publish JSON

<webr3> +1, but worry about putting names of companies on use cases, I know many many developers who would use objects+uri-ids+shared-properties

AndyS: When you try to convert data that is not RDF - it's difficult to do the detailed capture of meaning, we're going back to the knowledge acquisition task - difficult to do.
... The safest course would be to translate RDF to JSON in an easy way - JTriples, RDF/JSON
... JSON-LD is unproven territory, this WG on it's fast track is not the best place for it to happen.

Documents

SteveH: We're safe with SPARQL result set... anything else would be dangerous.

LeeF: I agree w/ Andy and Steve

<SteveH> not just SRJ, but any 3-column serialisation

Nathan: I have a split opinion, I agree with everyone - SPARQL result set is good - but we also need a way to do Objects w/ URI IDs - JSON-LD / JSN3 is overkill - maybe simplify them

Thomas: Pass... not knowledgeable enough on SPARQL.

Nathan: Quick question... it seems like w/ JSON-LD - you would like it to cover every use case - very simple to very complex.
... Why do you want everything in the one serialization.

<AndyS> Linked Data API is an example of lossy RDF->JSON (the mapping is domain specific)

<webr3> AndyS, JSN3 is like that, JSON-LD isn't

<tomayac_> (brb)

<Zakim> webr, you wanted to ask manu a q quickly

Nathan: JSN3 is setup in the Talis N3-way
... JSON-LD is different from JSN3
... There were three options - triples in JSON, TURLE-like view, objects in JSON

<tomayac_> (back)

Nathan: triples in JSON -> RDF/JSON, TURTLE-like view -> JSN3, objects in JSON -> JSON-LD

AndyS: The SPARQL result JSON format is almost like a CSV file - it also inherits design criteria from the XML results format.

<webr3> Nathan: JSON-LD currently like/covers all three (triples,turtles,objects)

<SteveH> +1 to AndyS on SPARQL JSON being ugly

AndyS: A solution to a problem at the time - it has taken off despite its history.

Thomas: Did we consider getting someone from the JavaScript community as an Invited expert?

<webr3> "give them something to hate" :D

<tomayac_> is someone going to www in india?

<AndyS> ADJOURNED

- DRAFT -

SV_MEETING_TITLE

21 Mar 2011

Attendees

Contents

Market Segments

Documents

Summary of Action Items

Scribe.perl diagnostic output