… markus, you put in a use of data annotations that I hadn't thought about, and we should discuss.
… For example 51, we have annotations used like a comment, which is not what I was thinking they were about, but they can certainly be used for that.
… It was primarily intended as a container type, and not a comment. In this case, it looks like it would be lost across expansion.
Markus Lanthaler: the reasoning was to describe it in a simpler way without relying on containers.
… Basically, annotations are data which survive expansion/compaction, etc. It would, though, be lost when going to RDF.
… This is the simplest way to describe the keyword.
… The Annotation Maps (ex 52), is used to show more advanced usage.
Niklas Lindström: I wonder if the choice of the name of the keyword is unfortunate. Was @key suggested?
… I'm not sure if this is helpful, because the primary use case was ex 52, and other similar situations when there is a corresponding property on the object itself, such asdc:language, or the text value of the date or author.
… It is primarily for artificial index keys which are necessary to allow the algorithms to work.
Manu Sporny: it was @index I had proposed, as I had looked at this as a way to allow indexes to survive.
Niklas Lindström: perhaps @key is even more appropriate; when you use @container, you can't hav several keys to confuse the mechanism.
… For one object, you cannot have several keys, otherwise the @container annotation would be confused.
… If a term were aliased to @annotation, and then use different terms, also aliased to @annotation, it would confuse the algorithms.
… The keyword @key is more explicit.
Manu Sporny: two questions, name of the keyword, and do we want to support bare string annotations.
Markus Lanthaler: not a question of support, just documentation.
Manu Sporny: leaning towards not documenting this usage
… This was not my intent when agreeing to use this mechanism. People could use things other than strings, which is not in the grammar, but people might think it follows.
… now we're describing another usage, as a basic string annotation, but not intended for use with the annotation maps.
… This becomes limiting.
… I'd rather not have this in there, and have them create a new term.
Gregg Kellogg: I'm inclined to agree - this is promoting using JSON-LD markup features when it's more appropriate to use things like rdfs:comment. [scribe assist by Manu Sporny]
Gregg Kellogg: By giving people a feature like this, we're giving people an excuse to not mark it up as Linked Data. Also, perhaps @annotation isn't a good name. [scribe assist by Manu Sporny]
Markus Lanthaler: I'd be fine with removing the example.
… Because the keyword is called annotation, the most natural thing is to use it for annotations. It's still there, but not L.D.
Manu Sporny: I'd say we could work on the intro, if needed.
Niklas Lindström: Lin, would you mind if the keyword @annotation (which is used for the extended language map feature) is renamed? Suggested name is @key.
Lin Clark: We haven't implemented that yet, so that's fine
Gregg Kellogg: Maybe this indicates that the "@annotation" name is bad? [scribe assist by Manu Sporny]
Manu Sporny: we want to show an equivalent of example 51, so people know how it round-trips.
… The section needs a bit more work.
PROPOSAL: "Remove Example 51: Data annotations" and provide different examples showing how data annotations survive expansion/compaction.
Gregg Kellogg: +1
Manu Sporny: +1
Niklas Lindström: +1
Markus Lanthaler: +0
RESOLUTION: "Remove Example 51: Data annotations" and provide different examples showing how data annotations survive expansion/compaction.
Manu Sporny: other ideas: @index, @map.
Niklas Lindström: it would look strange if looking at the expanded data.
Gregg Kellogg: @index is pretty descriptive of what's going on here. [scribe assist by Manu Sporny]
Gregg Kellogg: It seems to make sense in expanded form and in the context. [scribe assist by Manu Sporny]
Niklas Lindström: I think of this as the key in the map.
… I like @key in and of itself, but when looked at along other keywords, it looks odd.
Manu Sporny: I feel strongly about changing it from annotations to something else. Maybe we can change to @index, and see how people feel about it.
Markus Lanthaler: the problem I have with @index, that looking at an array, all elements are indexed, as in a cardinal location.
Markus Lanthaler: What about something like @marker
Gregg Kellogg: I agree that data annotations are going in the wrong direction, it doesn't matter what we change it to as long as it's in a better direction. [scribe assist by Manu Sporny]
Gregg Kellogg: "index into an object" works for most... I'd go w/ either @index or @key... @key is probably the most accurate, but @key next to @id and @type makes it not clear what it's used for. [scribe assist by Manu Sporny]
Manu Sporny: Gregg just convinced me that @index is probably the best.
Niklas Lindström: from the thesaurus, it looks like a reasonable choice.
Manu Sporny: also, this is editorial, it doesn't really effect the semantics.
Markus Lanthaler: why change, to prevent the use case or not promote it.
Manu Sporny: to be clearer about what the feature does.
Manu Sporny: The keys in a database don't really have semantic meaning, and aren't typically exposed to the application layer.
… This is effectively a database, and we are creating an index. The feature is easily comparable to a database index; not really an annotation mechanism.
… My understanding was that developers needed to access the data quickly, which is the definition of what a database index is used for.
… I think it's more accurate to say it's like a database index than an annotation.
PROPOSAL: Rename @annotation to @index and update the prose in section 6.14 to reflect the change.
Gregg Kellogg: +1
Manu Sporny: +1
Niklas Lindström: +1
Markus Lanthaler: +0.5
RESOLUTION: Rename @annotation to @index and update the prose in section 6.14 to reflect the change.
Niklas Lindström: Lin, we're going for @index. :)
Lin Clark: Thanks for the heads up :)
Topic: Update to JSON-LD Data Model
Manu Sporny: I was a bit concerned about these changes.
Markus Lanthaler: it MUST be either an IRI or BNode.
Gregg Kellogg: In RDF Concepts, it MUST be an IRI. [scribe assist by Manu Sporny]
Gregg Kellogg: but that's where we deviate from it. In SPARQL, it's an existential variable. [scribe assist by Manu Sporny]
Niklas Lindström: There is a difference between an existential variable and a bnode. [scribe assist by Manu Sporny]
Gregg Kellogg: Not really, a bnode is a non-distinguished variable. [scribe assist by Manu Sporny]
Gregg Kellogg: For JSON-LD - we are implicitly allowing bnodes to be used as graph labels. [scribe assist by Manu Sporny]
Manu Sporny: the concern I had was that each named graph is a pair, but since an IRI and BNode are nodes, it because something more like a "node class" mapped to a graph.
Gregg Kellogg: From Concepts: "Each named graph is a pair consisting of an IRI (the graph name), and an RDF graph"
Niklas Lindström: I talked with someone who thanked us for supporting BNode graph names.
Manu Sporny: for the spec, change "BNode" to "BNode identifier"
Markus Lanthaler: I'm worried about being inconsistent with the definition of node.
Manu Sporny: but this is a string to graph mapping. It is a pair of name (string) to graph. A node is not a string, but a bnode identifier is.
Markus Lanthaler: there's an issue of scopes then. The identifier is scoped to the document.
Niklas Lindström: in RDF, you can't have graphs within graphs, and BNodes only exist within a graph.
Manu Sporny: We're making use of BNOde identified graph, and need this in JSON-LD.
… It's based on timestampping elements and using them to identify graphs, rather than pretending we're creating an IRI of the graph.
Niklas Lindström: .. urn:uuid:....
Manu Sporny: we could use a hash identifier, but we tend to shy away from using new URNs when we can use a BNode.
Manu Sporny: we don't like UUIDs, because they look like garbage.
Niklas Lindström: I find BNodes useful, but BNode ids not so much.
… I only use BNodes for compound values, and occasionally, when I _really_ don't know the ID.
Manu Sporny: if we add them in here, we push the conversation forward.
Markus Lanthaler: we did discuss the differences already.
Niklas Lindström: if there's a good theoretical issue, it would be good to have in an explicit document.
Manu Sporny: so ask what the theoretical reason to not use BNode identifiers for graph names.
ACTION: Write e-mail to RDF WG asking why blank node identifiers can't be used for graph names and predicates.
Manu Sporny: the last change is terminology about saying a node is either a resource or a value.
Markus Lanthaler: I think we should remove "resource", as it confuses things.
Topic: Context via HTTP Link Header
Manu Sporny: Let's quickly bike-shed the name of this section.
Markus Lanthaler: Transforming JSON to JSON-LD
Markus Lanthaler: Referencing contexts from JSON documents
Markus Lanthaler: I think many people have JSON and would like to transform to JSON-LD if it doesn't require large changes.
Manu Sporny: I really like Transforming JSON to JSON-LD [scribe assist by Manu Sporny]
Niklas Lindström: is "transforming" the right idea?
The group decides that "Interpreting JSON as JSON-LD" strikes the right balance.
Manu Sporny: proposal to get rid of form and encode within profile.
… But, I think the prose around profile is confusing. I thought it was in case we had a schema which restricted the data.
Markus Lanthaler: the profile uses an identifier to describe some constraints or conventions used within the document, and mark the document with those conventions.
Manu Sporny: what about a link to a JSON schema?
Markus Lanthaler: the consumer must understand what the IRI means, so if the consumer knows about schemas, it could use it.
Niklas Lindström: I'm mostly thinking about content negotiation scenarios.
Manu Sporny: So get rid of form? Then we'd need the following two IRIs: http://www.w3.org/ns/json-ld#expanded http://www.w3.org/ns/json-ld#expanded-flattened ? [scribe assist by Manu Sporny]
Markus Lanthaler: you could specify in profile that you wanted a specific vocabulary.
Niklas Lindström: shouldn't the IRI be opaque?
… You need to link to it or have it in another link header.
… I wonder if it's good to define form to use the tokens "expand, compact", with or without "flattened".
… Gives four variations.
Manu Sporny: okay, proposals then - http://www.w3.org/ns/json-ld#expanded http://www.w3.org/ns/json-ld#compacted http://www.w3.org/ns/json-ld#expanded-flattened http://www.w3.org/ns/json-ld#expanded-compacted
Manu Sporny: those four, with either using "-" or "+" as separators.
Niklas Lindström: they might not need to be IRIs.
Manu Sporny: using IRIs allows other people to add their own profiles. Otherwise, we'd need a registry.
… The profile mechanism allows anyone to define their own.
… If they want to add a JSON schema, they can mint a new IRI for every one they expose.
PROPOSAL: Remove 'form' from the optional parameters for application/ld+json. Add four URL values for 'profile': http://www.w3.org/ns/json-ld#expanded http://www.w3.org/ns/json-ld#compacted http://www.w3.org/ns/json-ld#expanded-flattened http://www.w3.org/ns/json-ld#compacted-flattened
Manu Sporny: +1
Gregg Kellogg: +1
Markus Lanthaler: +1
Niklas Lindström: +0 (probably +1 but I haven't really considered the uses so)
David I. Lehn: +0
RESOLUTION: Remove 'form' from the optional parameters for application/ld+json. Add four URL values for 'profile': http://www.w3.org/ns/json-ld#expanded http://www.w3.org/ns/json-ld#compacted http://www.w3.org/ns/json-ld#expanded-flattened http://www.w3.org/ns/json-ld#compacted-flattened
Topic: Update on Algorithms
Manu Sporny: Dave Longley been working on his implementation, which is now complete. He is currently combining the text that Markus and Gregg wrote and expanding on the problem and general solution statements for each algorithm. Some of the algorithms are being re-written, but in a way that flows better and in a way that matches his implementation. So, once he's done, we should have a good middle-ground between what Markus and Gregg had, better prose outlining the algorithms, and some simpler algorithms. [scribe assist by Manu Sporny]
Niklas Lindström: .. "When @graph is used in a document's top-level object which has no other properties that are mapped to an IRI or a keyword it is considered to express the otherwise implicit default graph."
Niklas Lindström: my friend had a problem with this wording.
… If I understand him, he wasn't sure it was enough to add @id; he wanted to make sure he had a named graph.
Manu Sporny: The text is wrong, but let's try to fix it now. I'll make a change right after the call.