RDF Working Group Teleconference -- 24 Aug 2011

<trackbot> Date: 24 August 2011

<ivan> scribenick: tomayac

<ivan> -> Last meeting's minutes: http://www.w3.org/2011/rdf-wg/meeting/2011-08-17

Admin

<ivan> Last meeting's minutes: http://www.w3.org/2011/rdf-wg/meeting/2011-08-17

<ivan> PROPOSED to accept the minutes of the 17 Aug telecon

Accept Minutes from August 17

issues with many red boxes. ericP was the scribe

ivan: seems to have been a problem with the script. sandro takes care of that.
... maybe keep the minutes open, ask ericP, sandro to review.

PROPOSED keep the minutes open and ask sandro and ericP to review them

<ivan> http://www.w3.org/2011/rdf-wg/track/actions/pendingreview

ivan: most actions on people who are absent

<ivan> ACTION-74?

<trackbot> ACTION-74 -- Manu Sporny to send JSON discussion preparation message to public-rdf-wd -- due 2011-08-24 -- PENDINGREVIEW

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

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

manu: action-74 has been done

<ivan> http://www.w3.org/2011/rdf-wg/track/actions/open

ivan: for the other actions, we have to wait for people to come back

<ivan> ACTION-69?

<trackbot> ACTION-69 -- Gavin Carothers to update Turtle issue list to reflect current status -- due 2011-07-27 -- OPEN

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

ivan: one action on gavin

gavin: action on me is done

<PatH> I will be on IRC but probably not on the phone for this telecon.

ivan: action-69 closed
... action-78 closed
... one action on pat. pat on irc.
... i will take care of open actions to be closed

F2F

ivan: f2f
... pending issue for the f2f counterpart
... people interested in a bbc-hosted site
... offer still valid?

yves: pending manager approval

<PatH> I have a very old action which I confess I no longer can remember what exactly it actions me to do. Maybe someone with a better memory can jog me off-line in due course.

ivan: where is that?

yves: says location

ivan: hoping this will work out

<gavinc> Not exactly cheap in Boston either. :( Gone up since I was last there

ivan: anything else on that, yves?
... will be organized by Olivier Thereaud

<PatH> or persons unknown?

<yvesr> Thereaux

JSON work progress & planning

ivan: unsure where to start
... w/o going into the details
... manu and ian, just say a view words on the documents

ian: based on the talis format
... put up a working draft
... came out of the f2f
... draft is an overview of the format

<PatH> to be, or not to be, that is the question. Whether 'tis nobler in the mind of man to take up arms against a sea of hackers, and by opposing RDF them, or...

ivan: to have an idea, beyond the spec, do you have an idea of # of implementations and adopters, ian?

ian: at least half a dozen

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

manu: wrote a quick email
... based on initial set of feature of digital bazaar
... about 90% feature-complete
... continuing on public-linked-json@
... including non-typical semwebbers
... editorially 70-80% feature-complete
... four interoperable implementations, javascript, python, php, c++
... erlang in the works
... people seem to like it
... implemented in seevl.net by apassant

ivan: let's start w/ the knife fight
... calling thomas

<ivan> scribenick: manu1

Thomas: I sent an e-mail to the mailing list - JSON Emergency Brake - a bit controversial
... I made sure to check w/ all parties involved before sending it out...

<ivan> Thomas' email

Thomas: Tried not to offend anyone...
... I was co-editor of JSON spec. Ian comes up w/ first commit for RDF/JSON - then we could iterate over it.
... I was involved in public-linked-json list - paid attention as a listener... in-between two specs... overall, I felt that what we see in RDF/JSON is something that comes from the RDF camp - it doesn't really feel like JSON at all. We need to pull the emergency brake and stop the work on RDF/JSON and focus on JSON-LD.
... From the POV of a JavaScript developer, it doesn't feel like native JSON. It's a culture clash...
... JSON-LD is relatively easily mapped to triples. So, why do we have both?
... RDF/JSON feels like NTriples in JSON.

<PatH> Is there any RDF that CANT be represented in JSON-LD?

<ivan> scribenick: tomayac

<Zakim> iand, you wanted to say I am agnostic

<LeeF> It's definitely not a matter of "should be used for". More a matter of "is used for"

ian: i am agnostic
... it's not ideomatic json

<Zakim> manu1, you wanted to say that I feel pretty strongly about JSON-LD

ian: just a convenience format, mostly out of talis' needs

<gavinc> +q to say that TopQuadrant's position has changed

manu: not so agnostic, feel strongly about json-ld
... main concern i have, we could do a lot for linked data adoption
... i feel that json-ld is targeted at an audience we don't cover yet
... they don't want to go into the sparql, triple world

<PatH> question: JSON-LD maps to triples, but can it encode any RDF at all? Or is some part of RDF missing? What would it take to extend json-ld to cover all of RDF?

manu: they want linked data, but don#t want to do much to get it
... data exchange format for rdf people

<gavinc> PatH, I think rather JSON-LD can encode things that RDF -can't-.

<PatH> Maube , gavin, but what about the other way?

manu: you already have ntriples, rdf/xml, turtle, etc.

<LeeF> And yet despite those, people use RDF/JSON (or similar)

<LeeF> This is a standardization group.

manu: creating ntriples in json doesn't solve any problems imho

<iand> wasn't this all sketched out in a table by sandro?

manu: i feel that it doesn't necessarily grow the number of linked data

<LeeF> iand, yes, though i'm not sure the table was ever accepted by everyone :)

manu: json-ld attempts to move the existing json already oth there to a new level
... in order to get far more meaning
... converned of the use cases
... we have two technologies to tackle those
... it's like the microdata, rdfa thing again
... ivan, you didn't want this comparison
... heavy overlap of use cases

<PatH> I see a future here where json-ld seduces a lot of people into useiing RDF wihtout realizing they are using it. Which is great, but then what happens when they wake up and smell the RDF coffee: are they stranded by the limitations of json-ld, or can they move smpoothly intobeing real semweb people without having to learn a whole new set of tools?

manu: concerned that two last calls are published
... people might get very confused
... hoping we avoid that
... no one talked about microdata two years ago

<gavinc> PatH, I don't think there is any RDF that can't be expressed in JSON-LD

<Zakim> gavinc, you wanted to say that TopQuadrant's position has changed

<PatH> OK, great. Then I vote that we adopt json-ld

<iand> actually I see it differently, people may be seduced by having a nice JSON format so they write systems to consume it, but why do they need RDF at all?

gavin: our position has changed a bit
... we spent some time using and looking at json-ld

<PatH> Well, that is their problem. If they don;t need it, fine. BUt I supsect that many of them will, and those are the ones I care about.

gavin: we haven't implemented rdf/json

<iand> i think it's a mistake to hide the rdf model from developers because it's non-intuitive for many OO developers

gavin: unlikely we will implement rdf/json, we see limited value, different from the opinion we had a couple of months ago

ivan: on pat's question

<PatH> If nobody is going to implement it, its dead in the water.

manu: answering pat's question

<gavinc> I will say that TQ isn't everyone ;)

<NickH> RDF/XML = RDF for XML developers

<NickH> JSON-LD = RDF for JSON developers

manu: no rdf that can't be expressed in json-ld

<NickH> ?

<iand> manu1, does it have graph support?

<gavinc> And there are implementations of RDF/JSON

<NickH> Worried that JSON-LD hides the triples too much

manu: working on lists

<gavinc> RDF/XML is NOT RDF for XML developers, take that back! ;)

ivan: does it have graph support?

manu: what do you mean?

<PatH> Hey, rdf?XML hides the triples very effectively.

<PatH> rdf/xml

ian: (clarifies)

<NickH> PatH: yes!

manu: we can do graph literals, and we could support graph identifiers

<ericP> <g1> { <s1> <p1> <o1> } <g2> { <s2> <p2> <o2> } vs. <s1> <p1> { <s2> <p2> <o2> }

<ericP> i read graph literals as the latter

<PatH> what about blank nodes? I dont see how to get them into json-ld from a quick read.

<PatH> I guess that is meta-scribing.

ivan: what about blank nodes

manu: full blank node support

<PatH> OK, great. I'm a believer.

manu: people wanted us to describe the full process w/o calling rdf
... we were able to not reinvent rdf

<NickH> Does JSON-LD have any relation to RDFa profiles?

manu: we say unlabeled node instead of blank node

<ericP> "unlabeled node" is even consistent with the RDF concepts

manu: blank node support is there, and it made the normalization algorithm a nitemare

nickh: does json-ld have any relation to rdfa profiles?
... it seems very similar
... we don't want to make the same error as w/ rdf/xml w/ hiding triples

manu: the only relation to rdfa profiles is the @context

<manu1> "@context": "http://example.org/mycontext"

manu: in @context you can define the context
... meant to be put inline, but would be nice to be able to just declare it somewhere
... it can be a separate document
... same format as inline, just as a separate document
... it's a simple key/value map
... it has also type coercion rules
... we don't want to make the rdf/xml error of hiding triples
... we do this error
... we hide triples
... we wanted to present developers objects, not triples

<MacTed> RDF/JSON is limited to RDF. JSON-LD allows for other Linked Data models/implementations -- *with* full support for RDF.

<MacTed> RDF is limited to HTTP IRIs. JSON-LD allows for non-HTTP IRIs, among other things.

manu: triples can be easily and losslessly extracted, though

macted: json-ld seems to be a json superset
... believe that json-ld won't break any rdf

<NickH> Can you parse something similar to Talis JSON as JSON-LD?

ivan: i don't know whether we need to go into too much technical details
... rdfa has moved away from profiles

<iand> NickH: not really

ivan: a little amazed that json-ld still uses profiles

<NickH> ok, thanks

<Zakim> iand, you wanted to ask about datatypes

manu: we do it, as web devs are a different crowd than rdf people

<gavinc> +q to mention that the RDF WG may NOT be the best place to finish developing JSON-LD

<iand> my question was can json-ld represent properties that have multiple values with different datatypes

<gavinc> iand: Can you have properties with values with different datatypes?

<manu1> "foo:bar": [{"@iri": "http://example.org"}, {"@literal": "foo"}, {"@literal": "foo", "@datatype": "xsd:bar"}]

manu: responding to ian's question via code sample

ian: parsing the json, yes, question answered

ivan: how do we move forward?
... my understanding from the amsterdam f2f
... we were moving towards rdf/json as low level exchange format
... and json-ld in an incubator mode
... at some time look at json-ld again

<PatH> FWIW, my only gripe with the -ld document so far is some minor wording changes (mostly avoiding the word 'define' in various places).

<manu1> PatH, the language is rough and needs to be cleaned up...

ivan: has the incubator mode of json-ld come to a stage where we can look at it again

tomayac: +1 on having a look at it again

<gavinc> +1 to looking at JSON-LD again

<manu1> +1 to look at JSON-LD again.

<iand> happy for WG to look at json-ld again

<iand> +1

<MacTed> +1

<LeeF> -1

<NickH> +1 to look at JSON-LD again.

ivan: leef, can you explain?

<PatH> +1

leef: i don't think this wg is the right group

<yvesr> +1

leef: it should be addressed more by a web apps-ish group

<Zakim> gavinc, you wanted to mention that the RDF WG may NOT be the best place to finish developing JSON-LD

leef: just look up the old minutes

gavin: sharing lee's concern

<PatH> I dont see 'look at' as meaning 'take control of'.

<PatH> So I understand lee's concern but thinkit is misplaced.

<LeeF> PatH, I agree - the part I didn't add is that we have limited time & resources in the group

<PatH> probably me on IRC.

gavin: i don't think we have the right people to finsih json-ld

<Zakim> manu1, you wanted to discuss the right group

manu: sharing the same concerns of gavin

<NickH> yes, I agree that this might not be the right group of people

manu: everyone in this group is fantastic and has a strong history in rdf

<LeeF> Exactly. Couldn't agree more with what Manu just said

<yvesr> manu1, the BBC does, I would think

manu: but i don't think enough people in this wg use javascript and json enough in their daily lives

<SteveH> we use loads of JSON and Javascript

<LeeF> We use loads of JSON and JavaScript too, but not in the way that JSON-LD views the world

<SteveH> a bit of a simplistic generalisation

manu: the people on public-linked-json@ are the right people imho

<iand> we should also look (briefly) at the microdata json serialization which has some overlap

<gavinc> I did/do, but it's not exactly a TopQuadrant strong point at the moment.

<PatH> Who is in charge of json-ld right now? Can we simply advise them in a friendly way?

ivan: putting on the official hat
... we do not have a group that could take the place

<manu1> PatH - I'm the current editor and am running the calls, at the moment.

<PatH> suits you, Ivan.

ivan: the rdf group is still the closest one that could standardize this
... spinning off a separate wg would slow down the process
... also what tomayac said: if this work is going in the right direction, then publishing rdf/json is a strange message to send out
... we need to avoid any kind of message that could be misunderstood

<SteveH> +1 to LeeF

leef: not sure if it's practicable: but maybe this group should do either

<manu1> +1 to what Lee said - this group has enough on its plate.

<PatH> Is the issue that the intended audience would distrust the spec if it was emitted by this group? NOthing we can do about that if so. OR is it that we are less than ideally qualified to s=write this? If that is the issue, I suggest that we trust manu and make comments on drafts without being obstructive.

leef: we're busy w/ the core stuff
... speaking for myself, we should not publish either

ivan: not worried about the charter, quick remark

<PatH> I think that something needs to be given the W3C imprimateur. That matters to a lot of people out there.

<gavinc> In other words, can we write a JSON-LD-Triples ;)

<LeeF> PatH, I think the issue is the second. (At least, that's (one of) my concern)

<LeeF> PatH, I think it matters less to the people who are the core audience of JSON-LD, but that's purely speculation on my part

<PatH> Well, then, I dont see that as an issue. Y'all trust me to write the model theory, I m happy to trust manu to write the JSON stuff.

<PatH> OR whoever feels they know what they are talking about :-)

<gavinc> I just want to make sure we can get more feedback from other JSON developers

<iand> my question was: is there a profile of JSON-LD that subsumes what the purpose of RDF/JSON is, i.e. a regular structure that requires no parsing on client

<PatH> Yes, we always need that pre-publiish-last-call-comments stuff to go on, might take a little longer for this one.

manu: there is a structure that is an array of objects

<NickH> iand, a bit like N-Triples couple be a subset of Turtle but can be parsed faster?

manu: you can write it in such a way that it's only one level deep, normalization takes care of that

<iand> yes, like ntriples/turtle

manu: flat structure, ends up looking very much like turtle

ivan: 5 more minutes

<gavinc> 15 more minutes

ivan: not appropriate to decide something now

<PatH> just as long as it uses UTF-8...

<iand> manu: would you be able to send an example to the wg list?

ivan: my feeling is that on one hand json-ld might be more appropriate to happen in a separate community group that could be merged into a separate wg
... the second thing is we might suspend rdf/json work
... maybe even completely stop it
... rdf/json might be subsumed by json-ld
... this wg might focus on graphs etc.

<iand> +1 to ivan

<manu1> +1 to ivan

<gavinc> +1

ivan: only my opinion, or others agree?

<NickH> +1

<MacTed> +1

ivan: proposing to stop the json discussion

<PatH> not sure what we are voting on

ivan: reporting to the chairs, the discussion should go on via email

<PatH> +1

<LeeF> PatH, did you just vote affirmatively for an explicitly unknown question? :)

ivan: two more minutes to go

<PatH> I thought my question was answered...

<LeeF> ah ok, i missed that :D

ivan: ntriple issue and utf8

<PatH> OK, put the knives awy now, guys.

<gavinc> +q did the chairs/staff get the the comments from last week and emails about opening up the mailing list?

<gavinc> +q to ask if the chairs/staff get the the comments from last week and emails about opening up the mailing list?

ivan: proposes to adjourn the meeting

<PatH> OK, bye all.

ivan: ideally in one week we could have a final decision on the json issue
... meeting adjourned

leef: last question
... what was up w/ the mailing list?
... (explains) people from rdf-comments@ could not subscribe / post

gavinc: they are not wg members, but expected they could subscribe

ivan: this structure is not so unusual to have two mailing lists, also on other wgs
... by design
... we can rediscussed, but w/o the chairs, can't comment
... no strong feeling about it
... if the majority decides to change it, we change it
... adjounred, second time

<iand> bye all

<yvesr> bye!

<ivan> trackbot, end telcon

- DRAFT -

RDF Working Group Teleconference

24 Aug 2011

Attendees

Contents

Admin

Accept Minutes from August 17

F2F

JSON work progress & planning

Summary of Action Items

Scribe.perl diagnostic output