Dave Longley: Link above was a response Dan Brickley was working on for marking up the recording info requested by Ade
… Ade at google wrote a post liking to shane's article
… Conversations allow an opportunity to talk more about the motivations of JSON-LD
Gregg Kellogg: The whole Activity stuff wrt. Google - it was not well received at all, it made it seem like they were ignoring Activity Streams community. Guha came to defend schema.org and dispel myths and was not very effective at that. [scribe assist by Manu Sporny]
Gregg Kellogg: schema.org wasn't viewed nicely - they were kinda ignoring Activity Streams. [scribe assist by Manu Sporny]
Manu Sporny: we may want to think about distancing ourselves from schema.org and other initiatives; we've seen this happen before with RDFa.
… our strategy has been to talk about JSON-LD use anywhere.
… We don't want to pick sides.
Gregg Kellogg: One of my responses on Twitter, wrt. Microformats people, what it does w/ vocabularies - JSON-LD is vocabulary agnostic, Microformats isn't. [scribe assist by Manu Sporny]
Manu Sporny: MF is making some change about separating vocabulary from markup, but there is very little activity within that community now.
Gregg Kellogg: There is also a fair amount of presence by the IndieWeb community, Tantek being the main person there... they showed off some cool social media tech - indieauth... effective way to bring many communities together. Great forum for JSON-LD. Nothing we really need to do to follow up. Wouldn't worry about any of the schema.org stuff that came up there. They're such a big player that people are going to take shots at them. [scribe assist by Manu Sporny]
Manu Sporny: dbooth had sent out some minor changes to the Syntax and API specs.
David Booth: just editorial changes to smooth out some language.
… Text says it's a "generalized RDF dataset", but by default, it's standard. It also start talking about extensions before saying that there are extensions.
Manu Sporny: gkellogg and I reviewed the spec and could integrate it.
Markus Lanthaler: is it true that it serializes a standard dataset? It does allow you to put in blank nodes.
Gregg Kellogg: It's not syntactically invalid to use blank nodes in predicate positions like it is in TURTLE, so it can be serialized, but it does not result in those blank nodes being emitted when you turn it into RDF. [scribe assist by Manu Sporny]
David Booth: if the spec only constrains the end-result, then the end-result is standard RDF unless the option is specified.
Manu Sporny: I can see it both ways; I don't think the proposed change will make a big difference.
Markus Lanthaler: the description is somehow incompatible with the data model described in the spec.
Manu Sporny: I think dbooth's approach is to talk about serialization, and that is data model, so we're going to have differences.
Markus Lanthaler: the only place blank nodes are dropped is if you emit RDF.
Manu Sporny: is this paragraph about JSON or RDF?
Dave Longley: deserializing to an abstract syntax is the wrong term.
David Booth: maybe we can move "optionally" before "serialize".
Manu Sporny: let me look into it more and try to tweak the wording.
… We'll try to change the text to address both dbooth's and markus' objections.
Vikash Agrawal: I shared an update this week. Markus had some issues within the schema, as it did not include all classes and properties in schema.
Markus Lanthaler: bye dbooth
… using @vocab of http://schema.org/ means that specifying other vocabulary terms is not vital.
… I've moved on to the LinkedIn application.
… A question: I get JSON from LinkedIn, should I display that or a modified version?
… This could be the last coding project for the summer, then I could go on to documentation.
Manu Sporny: regarding the schema.org context, markus said it's not complete, but we had decided to just focus on the properties needed for specific classes.
… We'll need to eventually replace that with something machine generated; it shouldn't be that difficult to go through the schema and translate it.
Manu Sporny: perhaps a bonus project would be to do an algorithmic transformation of the vocabulary to JSON-LD context, and make it better.
Vikash Agrawal: I would go through a python crawler to retrieve it?
Manu Sporny: fetching a document from schema.org and transforming it into JSON-LD automatically, as the vocabulary will be updated over time. Having to do this manually is not a good long-term strategy.
Vikash Agrawal: so, I would get it every time it updates and re-generate the context definition.
Manu Sporny: don't worry about that now, we'll come back to it later.
Vikash Agrawal: the creator tool is done, and there are some validations left to perform.
Manu Sporny: sounds like you're going to work on the creator tool and LinkedIn app.
… don't work on the schema.org context anymore, and maybe come back to it later.
… The w3.org redirection is fine.
… the creator tool is a good first pass; we need to make the tool more generalized, so we can plug in different types of things. We'd like to do Organizations and other schema types, so they can't be hard-coded.
… The first pass was all that we asked for; one of the things you could do in the future would be to make it generic, for example having a JSON-LD file to describe the types and form elements.
Vikash Agrawal: Do you want me to make the creator tool more generic? Add those options you mentioned?
Manu Sporny: don't worry about them now, when you're done, we can come back to it.
… Is LinkedIn application published anywhere?
Vikash Agrawal: for LinkedIn, I won't be able to publish. If possible, you need to pull it down and test it on a local machine, so it can't be deployed (?)
… what should be presented in the application?
Manu Sporny: the ideal tool would allow you to put in a LinkedIn profile name, fetch the JSON, convert to JSON-LD and return it in a text-box.
Vikash Agrawal: I was thinking that after signing it, user would see both JSON and JSON-LD, or we could just show JSON-LD with computations in the background.
Manu Sporny: just show JSON-LD, but could have an "advanced" tab to show original JSON, but hide it by default.
Dave Longley: isn't the idea for the JSON-LD to look just like the JSON you got with an @context?
Manu Sporny: I was thinkingg it would be translated to schema.org markup, we would do the transformation.
Dave Longley: it might be good to see the JSON-LD just using a context, and then after you've converted it to schema.org.
Manu Sporny: my understanding of the purpose of the code is just to allow people to see their data as JSON-LD
Dave Longley: why wouldn't we want it to look as much as the original JSON as possible?
Manu Sporny: the data they publish is not very intuitive. The primary use case is schema.org, not LinkedIn.
Dave Longley: other people might want to reused the context for other uses.
Manu Sporny: that belongs in an advanced tab.
… I was hoping that people would just copy and paste the JSON-LD and put it into a file on their website, or into a script tag in their profile page.
Vikash Agrawal: an advanced tab would be a good way to do it.
Gregg Kellogg: Meta comment - your audio has been very difficult to understand, probably because you're not using a headset and possibly bandwidth issues. Please try to get a headset. [scribe assist by Manu Sporny]
Vikash Agrawal: I've had some problems with my data plan.
Manu Sporny: I think the major problem is the lack of a headset.
Topic: Review of JSON-LD 1.0 CR-ready specification
Manu Sporny: I prepped a spec last week for CR, including everything but dbooth's updates
… I think the CR spec is ready to go from an editorial perspective.
Dave Longley: my comment is that people have complained about overloading @type, either because they haven't read it, or it requires some more explanation.
Markus Lanthaler: the problem is that people aren't really reading the spec.
Manu Sporny: we could mark the use of @type in the context as at risk and introduce @datatype in the future.
Dave Longley: that's not the problem.
Manu Sporny: then the issue is a reading comprehension problem.
… they're not reading enough to know the difference. We've always had this issue.
Niklas Lindström: The problem is that the overloading of @type isn't carried through because we treat the concept of datatypes as something different than RDF types.
… Would @datatype change the distinction?
… It might address the problem unless people start to use @type instead of @datatype.
… OTOH, using @coerce in the context imply that people don't really think about type, but values.
… we could use @value instead of @type in the context
Markus Lanthaler: or allow @type to be used for data-injection, as people have assumed.
Manu Sporny: round-rripping becomes problematic, because we wouldn't know if to remove the type later
Niklas Lindström: that would mean that we could only do this for types, and not other properties.
… I would be fine with introducing @coerce, or @value
Manu Sporny: @coerce might have a similar problem
Dave Longley: we might need a different keyword
Niklas Lindström: the keyword should imply: "treat the string value as something other than a string"
Manu Sporny: just put an @ sign in front of that phrase!
Niklas Lindström: .. @coercevalue
Dave Longley: @interpretAs @interpret
… Let's put an issue marker next to this indicating that we might introduce a new keyword. Once people learn it, they don't forget it.
Niklas Lindström: could we propose to examine the possibility of another keyword.
Markus Lanthaler: what problem are we trying to solve? People don't know the different of types in statements or literals, this doesn't change that.
Manu Sporny: we could do @literalType
… People understand this once it is explained, and will resolve itself
Niklas Lindström: I think the use of @type in context does introduce a threshold which will never go away and will be a hurdle. I find it a bit strange when I look at the data. We have other specific keywords which send a specific signal.
… When I see @id and @type together, you have to wonder what it means.
Dave Longley: We should try to add an "explain" feature to the playground, which would go line by line to describe what the data means.
PROPOSAL: Add an issue marker for @type stating that we may introduce a new keyword to do literal type coercion.
Niklas Lindström: +1
Manu Sporny: +1
Dave Longley: +1
Vikash Agrawal: +1 (surely)
Gregg Kellogg: +0.2
Markus Lanthaler: -0.9
Niklas Lindström: (.. e.g. "@type": "@id" vs. "@coerce": "@id")
Markus Lanthaler: I don't think it will address the issue and just trigger more confusion.
Dave Longley: changing mine to a -1
Manu Sporny: by not putting it in the spec, it could cost us another 4 weeks. By putting into the spec, it enables us to change.
Vikash Agrawal: Can we have @expandTo
Markus Lanthaler: even if we add an issue marker, I think we would have to go back to LC
Manu Sporny: no, that's not how the W3C process works. you're allowed to do this if you've used an issue marker.
Markus Lanthaler: this looks like the API issue that put is back into LC
Manu Sporny: we're not into LC anymore, so the rules are different. We wouldn't actually need to go back to LC.
… The reason for this is to prevent from going from CR back to LC.
Niklas Lindström: .. also, recall that berjon first problem in the examples was "@type": "@id"..
Dave Longley: my vote is for least-friction, whatever that might be
Dave Longley: +1
Dave Longley: I'm willing to trigger more discussions if this will help.
Niklas Lindström: if manu isn't correct, then I expect markus and dlongley to actually vote -1 to making the change, if it comes to that.
RESOLUTION: Add an issue marker for @type stating that we may introduce a new keyword to do literal type coercion.
Manu Sporny: my assumption is that we won't make a change.
Dave Longley: danbri was confused about @type: @id, if you're expecting a URL or an object or array of objects (which you can).
Gregg Kellogg: Confusion there may be about type casting may work on things that are not bare strings... type casting is only meant to apply to strings. [scribe assist by Manu Sporny]
Markus Lanthaler: same for @language
Dave Longley: it could be to say "if a string is found in the value position, it will be used to interpret that". Highlighting that fact might be helpful.
… If you look at example 3, it's misleading.
… It should say if a string is encountered as a value, it should be interpreted as an IRI
Manu Sporny: I had that in spec-text before, but it was a lot to swallow in the 3rd example.
… It's going to be difficult for people to understand why we're being so specific.
Dave Longley: I don't think we need to make a lot of substantial changes, we could just say "if the values are strings, they can be interpreted as IRIs.
… We could say that in the example, and in the paragraph after the example.
… it's only a couple of words.
Niklas Lindström: .. something like "This means that any string associated with 'image' shall be interpreted as an object with this string as its identifier"?
Manu Sporny: I'm dubious that it will help, but fine in putting in some text.
Dave Longley: also after example 10, we could change the "even though …" text a bit to "since ..."
… text after example 3, 4 and 10
Niklas Lindström: I'm concerned about how we say that things are interpreted as IRIs. We really mean that it implies there's an object with that identifier. People already know that a string can be an IRI
… I think we're a bit in "RDF mode" in our minds, if they instead thought of the string as representing an object with an @id key.
Manu Sporny: these are editorial changes, which can be made after CR. We should focus on changes that need to be done before CR.
Manu Sporny: any concern about JSON-LD 1.0 spec for CR?
PROPOSAL: Request that the RDF WG publish the JSON-LD 1.0 Candidate Recommendation on August 22nd with a CR period of 4 weeks.
Manu Sporny: +1
Dave Longley: +1
Gregg Kellogg: +1
Niklas Lindström: +1
Markus Lanthaler: +1
David I. Lehn: +1
Vikash Agrawal: +1
RESOLUTION: Request that the RDF WG publish the JSON-LD 1.0 Candidate Recommendation on August 22nd with a CR period of 4 weeks.
Topic: Review JSON-LD 1.0 API CR-ready specification
Markus Lanthaler: had a question about exit criteria, which was taken from another spec.
… Also about @context, on how it can be accepted. The only thing that isn't support is an array of objects having @context.
… We could support this, but it would need to change the API algorithms.
… This could mean that some problems wouldn't be found.
… You could embed a context with another context, which would be problematic
Manu Sporny: is there a major use case we're missing?
Markus Lanthaler: I really don't see a use case, just what you presented last week, but that can be implemented quite easily.
… It's really about allowing some syntactic sugar which isn't currently allowed.
Dave Longley: my implementation allows it, but I don't really care that much. Markus is right that you could do this in pre-processing pretty easily.
Manu Sporny: I think it's safe to not add at this point, we can always come back to it in the future.
… I have some concerns about the explanations of each section. Since it's the API spec, I don't think it's super critically, but we might want to make language more accessible during and after CR
PROPOSAL: Request that the RDF WG publish the JSON-LD 1.0 API spec as a Candidate Recommendation on August 22nd with a CR period of 4 weeks.
Manu Sporny: +1
Dave Longley: +1
Markus Lanthaler: +1
Vikash Agrawal: +1
Gregg Kellogg: +1
Niklas Lindström: +1
David I. Lehn: +1
RESOLUTION: Request that the RDF WG publish the JSON-LD 1.0 API spec as a Candidate Recommendation on August 22nd with a CR period of 4 weeks.
Manu Sporny: markus and gregg, please propose to move to CR on the next call.
Topic: Implementations and Test Suite
Gregg Kellogg: mine's up to date.
Markus Lanthaler: Mine does to, except for new @context stuff.
Niklas Lindström: the rdflib JSON-LD does for python