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...

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

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?

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.

<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