- From: Manu Sporny <msporny@digitalbazaar.com>
- Date: Sun, 21 Oct 2012 19:44:14 -0400
- To: Linked JSON <public-linked-json@w3.org>
- CC: RDF WG <public-rdf-wg@w3.org>
Thanks to François for scribing! The minutes this week's call are now
available here:
http://json-ld.org/minutes/2012-10-16/
Full text of the discussion follows including a link to the audio
transcript:
--------------------
JSON-LD Community Group Telecon Minutes for 2012-10-16
Agenda:
http://lists.w3.org/Archives/Public/public-linked-json/2012Oct/0008.html
Topics:
1. Wikidata visit
2. RDF WG Face-to-face
3. Drupal JSON-LD Vendor extension
4. ISSUE-113: IRI compaction algorithm
5. ISSUE-114: JSON-LD grammar
6. Issue review
7. Thoughts on .link()
Resolutions:
1. Add an optional parameter to the application/ld+json
mimetype called 'profile' where the value associated with it
SHOULD be an IRI.
2. Move all examples in the JSON-LD Grammar section of the
spec to the main body and point to them with links.
Action Items:
1. Niklas to review spec text for ISSUE-125.
Chair:
Manu Sporny
Scribe:
François Daoust
Present:
François Daoust, Manu Sporny, Gregg Kellogg, Markus Lanthaler,
Niklas Lindström, Lin Clark
Audio:
http://json-ld.org/minutes/2012-10-16/audio.ogg
François Daoust is scribing.
Markus Lanthaler: http://groups.drupal.org/node/261843
Manu Sporny: additions to the agenda?
Gregg Kellogg: need to discuss availability for RDF WG F2F
agenda
Markus Lanthaler: discuss article from Lin on need to have two
different serializations of JSON-LD.
Gregg Kellogg: It's not unlike what Wikidata has to do.
Manu Sporny: I wonder if it's a limitation in JSON-LD or whether
this has nothing to do with JSON-LD. Sounds like the latter.
Markus Lanthaler: I think it's really two use cases.
Topic: Wikidata visit
Gregg Kellogg: I went and visited about half a day Wikidata
Germany. Spoke with several developers including Denny.
… In August, they sent out something about SWIG about their
RDF serialization issues.
… Last message is August 9th.
… We discussed a little bit and it brought some issues.
… Brought us to an example with an item and its pronunciation.
End up using two bnodes.
… Normally, that would be an RDF value but it doesn't seem to
be particularly mainstream.
… Lowercase 'title' that would a language map and
pronounciation and upper case 'TITLE' that would possibly have
nodes on which they can hang data.
Manu Sporny: A bit strange
Gregg Kellogg: It is, but it helps with the API.
… JSON-LD gives you unique IDs for properties and context that
gives you certain amount of typing, allowing you to distinguish
between literals and objects.
… [example of Wikia and hybrid export]
… I probably need to write a blog post about that.
… JSON-LD is alive and well but not firmly established right
now.
Manu Sporny: release schedule?
Gregg Kellogg: They have something right now. Schedule for real
deploy end of March.
Niklas Lindström: First, quick reflexion. It seems that the Wiki
idea of the upper case title property sounds like SKOS-XL
structure
Gregg Kellogg: it bears some similarity, yes.
Niklas Lindström: ..
<http://www.w3.org/TR/skos-reference/skos-xl.html>
Gregg Kellogg: From their perspective, only two formats of
interest RDF/XML and JSON-LD, interesting.
[short discussion on merits of different RDF serializations]
Gregg Kellogg: Here's the swig thread:
http://lists.w3.org/Archives/Public/semantic-web/2012Aug/0021.html
Manu Sporny: Wikidata export in RDF -
http://lists.w3.org/Archives/Public/semantic-web/2012Aug/0021.html
Gregg Kellogg: [explaining definitions of properties into
classes and subtypes]
Niklas Lindström: .. "properties": {"@rev": "rdfs:domain"}
Niklas Lindström: I've done the same thing when I generated
documentation from owl. My general reflexion, it sounded like
what I've been doing in my own framing. I just wanted to note the
similarities.
Manu Sporny: is there anything that this group should do?
Anything they're waiting from us?
Gregg Kellogg: most important thing is to get to REC. Syntax is
key to them more than the API at this point.
… Quite a lot of discussion, that was pretty good.
Manu Sporny: Good, thanks for the time you took to reach out to
them.
Topic: RDF WG Face-to-face
Manu Sporny: I can definitely attend the F2F remotely.
Gregg Kellogg: RDF WG Agenda:
http://www.w3.org/2011/rdf-wg/wiki/FTF3#Agenda
… Anyone else planning to be there?
Gregg Kellogg: JSON-LD is on day 2 at 13:30 to 14:30 local time
in Lyon. GMT+1, I think.
… I don't necessarily feel compelled to be on, it's fairly
early for me.
… Manu, if you can be on for that, that would be good.
Manu Sporny: I'll be on.
François Daoust: I will be in the room. [scribe assist by Manu
Sporny]
Markus Lanthaler: I'll be there remotely as well.
Gregg Kellogg: François will be at the RDF WG F2F too
Manu Sporny: good to have people.
Gregg Kellogg: the generic goal is to bring the specs to LC.
… The idea would be to resolve issues by then, or to flag
issues that remain to be resolved before LC.
Manu Sporny: We have a number of outstanding issues waiting for
people to add something or propose spec text.
… We discussed language maps.
Gregg Kellogg: that probably deserves a bit of discussion
because of cases that prevent round-tripping.
Manu Sporny: I think that's the biggest issue.
… I don't think we'll be able to say the doc is LC-ready.
… but we won't have much things to discuss anymore.
Topic: Drupal JSON-LD Vendor extension
Markus Lanthaler: Two JSON-LDs for Drupal:
http://groups.drupal.org/node/261843
Markus Lanthaler: Enable standard literal handling for RDF-ish
domain models: http://drupal.org/node/1813328
Markus Lanthaler: Decide how to negotiate between the 2 JSON-LD
serializations: http://drupal.org/node/1797210
Markus Lanthaler: I don't know much more, I just read that post
where Lin basically outlines that they seem to need two different
JSON-LD serializations.
… Data structure is different for each one.
… For one use case, given an article, the body of the article
would be a bnode, and on the other hand, they want to model their
data in a more "user-friendly" way.
Gregg Kellogg: there is actually a class for a Web page fragment
in schema.org, which would be reasonable to use.
Manu Sporny: We should definitely continue to talk with Lin and
see if there's something we can do.
Gregg Kellogg: From a modeling perspective, you might say that
an article has a body and a description. Saying that it has a web
page fragment kind of crosses domains.
Markus Lanthaler: http://schema.org/Article
… There are ways to do that, but that starts to be a little
weird.
Markus Lanthaler: articleBody Text
Manu Sporny: anything we can discuss here in the absence of Lin?
Gregg Kellogg: Lin, we're discussing your dual-use of JSON-LD now
Lin Clark: oh, give me two minutes and I'll join
Markus Lanthaler: two issues raised, on negotiation between the
2 serializations and handling for RDF-ish domain models.
Niklas Lindström: I just want to make sure that I understand
this. This is a general modeling problem, it doesn't seem to be
an issue with JSON-LD, nor with RDF as an expression model.
… That's just a basic problem of "simple vs. complete".
… It's always a trade-off.
[Lin just joined the call]
Manu Sporny: Hi Lin, anything we could do to address these
issues or are they best handled by the Drupal community?
Lin Clark: I honestly don't think that you need to change the
spec for this.
… I'm pretty sure that this is something that we need to deal
with internally.
Markus Lanthaler:
https://github.com/json-ld/json-ld.org/issues/16#issuecomment-6327597
Markus Lanthaler: we discussed that before. Wondering about
using "profile" to distinguish between serializations.
Lin Clark: we should have content conneg added later on.
Manu Sporny:
http://json-ld.org/spec/latest/json-ld-syntax/#iana-considerations
Markus Lanthaler: the change would be quite trivial, simply add
a profile to the MIME type declaration.
Manu Sporny: the optional parameter that we would have would be
"profile" and people could use a URL or a string value.
… Lin, would that work for Drupal?
Niklas Lindström: .. "profile" or "context"?
… It would still be application/ld+json but completed with a
"profile"
Lin Clark: I think that that should work with us.
Markus Lanthaler:
application/ld+json;profile=http://drupal.org/profiles/deploy
Manu Sporny: Any comment on whether it should be a text string
or an IRI?
Lin Clark: It does not matter too much for us.
Manu Sporny: I think I prefer to do an IRI, just because it's
very specific.
Gregg Kellogg: +1
… You don't want two people to use the same string for
different purposes.
Niklas Lindström: +1
François Daoust: +1
Manu Sporny: It sounds that we have general agreement for this.
Niklas Lindström: should it be "profile" or "context"?
Manu Sporny: Two different things in my view, the "context"
points to a very specific JSON-LD context. The profile conveys
the generic layout of the data. You may use multiple contexts but
still one profile.
Gregg Kellogg: note there's nothing that prevents using a
context IRI for the profile IRI
PROPOSAL: Add an optional parameter to the application/ld+json
mimetype called 'profile' where the value associated with it
SHOULD be an IRI.
Markus Lanthaler: +1
Manu Sporny: +1
Gregg Kellogg: +1
Niklas Lindström: +1
François Daoust: +1
Lin Clark: +1
RESOLUTION: Add an optional parameter to the application/ld+json
mimetype called 'profile' where the value associated with it
SHOULD be an IRI.
Markus Lanthaler: Created issue 164 for this
Markus Lanthaler:
https://github.com/json-ld/json-ld.org/issues/164
Gregg Kellogg: the other thing we talked about was about Web
page fragments. You could have intermediary nodes using
primaryTopicOf and so on.
Lin Clark: The only reason why we used schema.org is because
it's a common vocabulary but users may build and use other
vocabularies.
Topic: ISSUE-113: IRI compaction algorithm
Manu Sporny: https://github.com/json-ld/json-ld.org/issues/113
Manu Sporny: Initial concern by Markus. Gregg suggested we made
it very simple. The counter-argument to that is that it leaves
some leeway in some compaction cases. I proposed to deal with it
in rounds. I talked with Dave Longley about that, but that would
end up with something that is actually more complicated than what
we have now.
… The term ranking thing that we have seems to be the most
reasonable thing for everyone in the end.
… We did talk about your algorithm, Markus. Dave Longley felt
it was different but not necessarily simpler.
… In short, I think that where we are right now is: no reason
to change anything as the only other proposal on the table does
not bring a lot. Markus, what do you think?
Markus Lanthaler: I personally find my proposal simpler because
you understand it when you write it on a sheet of paper and
because I implemented it this way.
… The algorithm is already there but I did not really
understand it so could not implement it.
Manu Sporny: That's my main concern. If one people in the group
does not understand how to implement it, it does not start very
well.
Markus Lanthaler: You can follow the steps and implement the
algorithm. It just looks like code so you just won't understand
how it's supposed to work.
Manu Sporny: Indeed, I don't disagree with any of the points
you're making. I just think we have a time issue here.
… We should prepare a more prose version that we could put
side by side with the algorithm in the code.
… It would take time though.
Niklas Lindström: There are some good examples in the comments.
Is there a comprehensive set of tests for that?
Gregg Kellogg: Yes, there are. The problem is that tests often
test for multiple things, so it may be hard to figure out what
precisely is a problem.
Manu Sporny: That speaks more to "we need to fix the test
suite".
Gregg Kellogg: If you implement things correctly, tests will
pass and are great, but don't help you much when you fail.
… Perhaps what we could be doing is adding annotations to the
spec.
Manu Sporny: your proposal would be to add issue marker to
algorithms that are not clear enough?
Gregg Kellogg: Yes
Manu Sporny: And then we could go to Last Call.
Niklas Lindström: Manu, is your implementation currently using
the algorithm in the spec?
Manu Sporny: Dave would know. I think so.
Markus Lanthaler: otherwise we wouldn't have one implementation.
François Daoust: I think that JSON-LD is in good shape regarding
text and algorithms. I wouldn't worry too much about how the
algorithm is defined, usually done after LC... that's what you do
during CR. It's not such a big deal because we will need to
refine the algorithms. [scribe assist by Manu Sporny]
François Daoust: We have done this before with W3C specs and it
worked out just fine. [scribe assist by Manu Sporny]
Manu Sporny: let's mark the spec with an issue marker, saying
that the algorithm might be refined for clarification purpose
after last call.
Markus Lanthaler: I also have an implementation that passes all
the tests. It may not be worth spending time adding issue
tracking. Basically, I'm proposing to do nothing. We should check
whether the current text passes the test suite.
… and update the text if it doesn't
Gregg Kellogg: or update the test suite.
… I'll go straight to where I'm failing and see if I can
resolve those issues.
… If I can make mine pass or find something that we disagree
about this week, that would help us for next call.
… Also, note that I don't think that we have tests for
"flatten".
Manu Sporny: We should do that, although that should not block
us from going to last call.
Gregg Kellogg: finding an online test runner was very effective
for RDFa too.
Niklas Lindström: I note that I also prefer data to algorithms.
[Manu actioning people to check tests]
Topic: ISSUE-114: JSON-LD grammar
Manu Sporny: https://github.com/json-ld/json-ld.org/issues/114
Manu Sporny: I think we're pretty much done with issues that
could modify the spec dramatically.
… This one was on hold for other issues.
Markus Lanthaler: The grammar is too long so you can't get a
quick overview of what's allowed where and what is not. I think
it's 3 or 4 pages right now, it should be down to half a page.
Gregg Kellogg: I think that if you look at the text, the
intention is to be very descriptive. It strives to be extremely
precise of what could be happening without duplicating text.
… I would be satisfied if the introduction sections references
sections that details them.
… That said, replacing with a short text is going to be very
challenging, I think.
Manu Sporny: +1 to putting in references back to examples in the
spec. +1 to it being difficult to distill it down to 1/2 to one
page.
… [looking at node definition]
… I'm not convinced that making it smaller by removing that
context is an improvement.
… Mostly, it's pretty much the examples that are sort of
fluff.
Manu Sporny: Two statements from Gregg I agree with: 1.
difficult to go down to one page. 2. to reference examples in the
spec.
… I don't think we should be doing more than that. Removing
examples should already give us what we need.
… Markus, if just those two changes are made (removing
examples and pointing to them), would that be enough for you?
Markus Lanthaler: Yes, I think I'd be ok with that.
PROPOSAL: Move all examples in the JSON-LD Grammar section of
the spec to the main body and point to them with links.
Gregg Kellogg: +1
Manu Sporny: +1
François Daoust: +1
Niklas Lindström: +1
Markus Lanthaler: +1
[discussion about example IDs not generated by ReSpec for the
time being]
RESOLUTION: Move all examples in the JSON-LD Grammar section of
the spec to the main body and point to them with links.
Topic: Issue review
Manu Sporny: OK, let's make a really quick pass to remaining
issues to see where we are.
Manu Sporny:
https://github.com/json-ld/json-ld.org/issues?milestone=2&page=1&sort=updated&state=open
… 6 open issues.
… ISSUE-114, just resolved.
… ISSUE-159 on language containers, we still need to discuss
… ISSUE-142: resolved
… ISSUE-163: will work on this
… ISSUE-133: should be marked as resolved
… ISSUE-157: I sent an email to Richard Cyganiak. He should be
able to find some time in the next couple of weeks.
Manu Sporny:
https://github.com/json-ld/json-ld.org/issues?milestone=1&page=1&sort=updated&state=open
… 8 open issues on the API.
… ISSUE-113: pending tests feedback as discussed today
… ISSUE-151: waiting on Dave Longley
… ISSUE-153: waiting on Dave Longley
… ISSUE-160: resolved
… ISSUE-140: deferred to JSON-LD Next (after some discussion
at end of call today)
… ISSUE-162: need discussion
… ISSUE-156: need discussion as well
… ISSUE-125: done, I think. Where are we on that, Gregg?
Gregg Kellogg: I thought I had done that. Maybe Niklas could
have a look to see where I'm clear/unclear.
Manu Sporny: Niklas, could you take an action to review that?
Niklas Lindström: Yes.
ACTION: Niklas to review spec text for ISSUE-125.
Manu Sporny: We have 3 issues that we need to discuss next week.
Once those are resolved and text updates are made, we should be
ready to go to Last Call.
Topic: Thoughts on .link()
Niklas Lindström: One thing I've been thinking about is whether
we should take a stripped down version, a "connect" that doesn't
do anything more than connecting IDs.
… If we wanted to include something like this in 1.0, we
should probably do something simpler.
… If we put something in 1.0, basically, we should put an
algorithm to produce an ID map.
Gregg Kellogg: we have one already
Niklas Lindström: Yes, so we could use it.
Manu Sporny: It's just to get a map of subjects to data.
Niklas Lindström: where is that algorithm used? Flattening?
Gregg Kellogg: Framing.
Manu Sporny: The one step generalization of what Niklas is
proposing is a ".index" function that would index the data by the
provided key.
… What the algorithm would do is flatten everything and search
for the index property that you gave it.
… Just to be clear, this isn't "connect", it's "index".
… You would just get key-value pairs.
Gregg Kellogg: It just feels like creaping features in the spec
at that stage.
Niklas Lindström: Perhaps the most reasonable thing to do is to
continue working on it in a separate spec.
Gregg Kellogg: What makes these things a little bit experimental
is when applied to expanded form.
… so there's value leaving it outside of the spec for the time
being.
Niklas Lindström: One way to explain it is to say it turns
JSON-LD Data into objects that are backed by an RDF graph and it
makes leveraging that structure to manipulate data easily.
Manu Sporny: From what I hear, we have use cases but are not
going to put it into 1.0 spec.
Niklas Lindström: …
https://github.com/json-ld/json-ld.org/blob/master/test-suite/tests/expand-0028-in.jsonld
Manu Sporny: Anything else?
Niklas Lindström: I just found a test that uses @vocab with a
notion of data that has not ID. Since there is no context, it's
resolved against the vocal.
… I wonder if it's the right behavior.
Gregg Kellogg: no other interpretation where it would make
sense, or it wouldn't expand to an IRI.
[discussion about @id: null, the spec tells the processor to
ignore it]
Markus Lanthaler: http://bit.ly/QPnv9a
Markus Lanthaler: not handled in the playground, neither in my
implementation. So prob. not in the spec
Manu Sporny: we should create an issue for it to track this as
I'm afraid we'll lose it.
-- manu
--
Manu Sporny (skype: msporny, twitter: manusporny)
President/CEO - Digital Bazaar, Inc.
blog: HTML5 and RDFa 1.1
http://manu.sporny.org/2012/html5-and-rdfa/
Received on Sunday, 21 October 2012 23:44:47 UTC