Manu Sporny: there's a discussion on the rdf wg list initiated by cygri about this
Gregg Kellogg: there are many things discussed
… the of the problem as described is that our data model is unclear
…. we should be more discinct regarding wha'ts the json data model and the linked data model
Manu Sporny: +1 to node definition / node reference
… the subject/object definitions are not good as they stand, we should address this. probably in the direction of using nodes
… there are issues on what a properly/predicate is, graphs
… and whether json-ld actually can have *many* nodes with the same id or not
… we should go through point by point
Manu Sporny: out of cygri:s 3 suggested strategies, we have one: align with rdf terminology as much as we can
... but cygri sees more differences between rdf model and json-ld model than there already are
… i think that richard's right in that json-ld model is less restrictive
… predicates could be strings/literals: but there's no semantic meaning to them yet
Gregg Kellogg: we probably contradict ourselves in regard to what subjects can be
… id is always an IRI
Manu Sporny: yes, that comes from early days of JSON-LD, where we didn't want to set that in stone
… we could make it stricter, but we may lose something
Manu Sporny: but we may lose the people who say that linked data is not rdf
Gregg Kellogg: we haven't heard from them for quite some time, and we are part of the RDF WG
… if we need for ID:s to be just strings, we would need some syntax for that, etc.
… occasionally, these topics are brought up in the rdf wg group
Niklas Lindström: These things do come up in RDF discussions, and Semantic Web and Linked Data mailing lists for many years - they say, "Perhaps we should allow plain strings as subjects and predicates"? Subjects should allowed to be literals. [scribe assist by Manu Sporny]
Niklas Lindström: When I come to think about those arguments, they're not very compelling. They look to extend the RDF data model into something more pure. Literals as subjects are not a good argument because the concept of literals is impure. It's a practical definition. [scribe assist by Manu Sporny]
Niklas Lindström: The difference between type and datatype, for example. I agree with a lot of what Richard is getting at. I find some of the parts a little too misunderstood, I think that there is a bit of a danger of leaving the JSON-LD data model as too lax. [scribe assist by Manu Sporny]
Niklas Lindström: What I like about RDF is that everything is defined, there is no wiggle room for creative extensions. That restriction means that I can understand any data that I can get. [scribe assist by Manu Sporny]
Niklas Lindström: You see this "extension" ability in Atom, people experiment, but you never really see these extensions catch on because there is no real interoperability. [scribe assist by Manu Sporny]
Niklas Lindström: I'm concerned that we may end up in the same situation. Undefined terms may /mean/ something, but I'd rather that we say that they're dropped entirely from the level of semantics. [scribe assist by Manu Sporny]
Niklas Lindström: They're more structured code comments than semantics that extend the RDF model. [scribe assist by Manu Sporny]
Manu Sporny: on a high level I agree. I can see these arguments.
... but I don't see the pure theoretical things as such. In JSON, they are used directly. It's not fair to label that as theoretical.
… we don't have an alternative model to map to than RDF
… if you use things that aren't mapped to that. If somebody comes up with another data model in the future, that data model could be supported..
… until then, we can say that subjects and predicates must to IRIs
Gregg Kellogg: currently we say "should" on e.g. predicates are IRIs
… It was glen mcdonald who argued that the language should support it
… if you can't have a JSON object with a key that cannot be mapped to an IRI, it's just dropped when we expand
... we support the expressions in the data, but they are dropped on expansion
Gregg Kellogg: wrt strings as subjects and properties, e.g. notation 3 use that for productions
Niklas Lindström: Yes, that's true. The "theoretical" comment was about the current arguments to why these should be a part of RDF. I've seen these as a part of N3 as well. It depends on how you want to interpret this. The problem is that we don't say anything about that. [scribe assist by Manu Sporny]
Niklas Lindström: I think the issue is that Richard is unsure about whether we support a model that is more akin to N3, but we don't say anything about that - we do say a lot of "mights" and "possibles" - we should constraint the language a bit more. More clearly state it. [scribe assist by Manu Sporny]
Niklas Lindström: Maybe we should say that the JSON-LD data model supports these things, and that they're not translatable to RDF. [scribe assist by Manu Sporny]
Niklas Lindström: We may want to say that we drop anything that can't be translated to RDF. [scribe assist by Manu Sporny]
Gregg Kellogg: I think the issue is that if we support a broader data model than RDF, we have to talk about what that is. [scribe assist by Manu Sporny]
Gregg Kellogg: the problem is that if we define a larger data model without providing the semantics for it is problematic
Manu Sporny: I'm fine with changing the language so that we constrain what is understood as linked data in JSON-LD now
… the idea is that we can extend it later on if needed. but at this point we constrain id and properties to IRIs.
… in the future, we *could* use something ilke @sid as string-id or similar
... doing that we *could* support data model extension like that, but do not at this point
Niklas Lindström: I like that approach - it makes it clear that we can support that in the future, but not right now. Hopefully, it should address the issues that Richard has. [scribe assist by Manu Sporny]
Gregg Kellogg: it's inevitable that we should do this, to make our lives easier. but before we do that we should propose those changes with clearly stated reasons why, to give people who might have a stake in that have a chance to speak up
Manu Sporny: yes. the devil's in the details, so we need to see a final proposal to understand the implications
… we also have the terminology issue to change subject/object terms
Markus Lanthaler: we must consider what subject maps means for this
Gregg Kellogg: in json, the key is called a name
… we can define that as the key position, and define what it means in rdf terms (a property)
… and subjects/objects we should refer to them as nodes
Manu Sporny: but we want to differentiate between node definition and node reference, right?
Gregg Kellogg: richard says node object and reference object
Gregg Kellogg: If you stop using the term “object” for the “nodes” of a JSON-LD graph, then I'd think that terms like “node object” and “reference object” instead of “node definition” and “node reference” might be better, because they're kinds of JSON objects.
Markus Lanthaler: do we need to differentiate between them?
Gregg Kellogg: if we say a node definition, that implies that it represents the node in full
... from a data model perspective the node is the *union* of all the json objects with that id
Manu Sporny: we have the node itself; only in the data model. then we have the node definitions, and node references.
Gregg Kellogg: if we do this, we should add a flatten api method
Manu Sporny: I'm not sure; it could eat a lot of time, and we could document it properly
Gregg Kellogg: we have a complete description by markus
Manu Sporny: do we have agreement on the suggested renaming?
PROPOSAL: Rename "subject definition" to "node definition" and "subject reference" to "node reference"
Niklas Lindström: +1
Gregg Kellogg: +1
François Daoust: +1
Markus Lanthaler: +1
Manu Sporny: +1
Manu Sporny: we're striving on using the same terminology across all specifications
RESOLUTION: Rename "subject definition" to "node definition" and "subject reference" to "node reference"
Markus Lanthaler: is the distinction necessary in the data model?
Niklas Lindström: I think Richard said that he thinks we make a distinction between the node and the IRI that labels the node. [scribe assist by Manu Sporny]
Gregg Kellogg: we haven't said that an object is a node reference. it may be that, or a value (literal?). and a node reference may use an IRI or a bnode.
Manu Sporny: we went through 3 months defining this. we can adapt the terminology here, but if we change it all to RDF, we've said linked data == RDF.
Manu Sporny: we use subject 70+ times in the document, and object some 43 times. 49 are subject definitions...
Manu Sporny: our definition of linked data, by itself, should be clear and simple enough
Gregg Kellogg: but if it is RDF, we should use the same terms
Niklas Lindström: we're talking about the resulting data graph (realized e.g. by parsing json-ld with a "connect"/"link" algorithm into an in memory graph). But that's neither the abstract triple structure of a graph, nor the denoted "knowledge graph"
Niklas Lindström: So, let's work with Richard on this and try to find some common ground. It would be fine if we clearly say what we're describing... it's tangible, but perhaps somewhere inbetween the abstract and the concrete may be okay. [scribe assist by Manu Sporny]
ACTION: Manu to setup a phone call with Richard Cyganiak to discuss RDF/JSON-LD terminology.
Niklas Lindström: We mean almost exactly the same things... maybe we should find where we differ and go from there. [scribe assist by Manu Sporny]
Niklas Lindström: We want JSON-LD to be a path to RDF w/o all of the theory up front. [scribe assist by Manu Sporny]
Manu Sporny: My concern is that if we point RDF Concepts to people, that is a losing strategy with Web Developers... if we can't explain it in 2 paragraphs or 10 items in a list, we've failed. [scribe assist by Manu Sporny]
Markus Lanthaler: Just found this in RDF Concepts: The predicate itself is an IRI and denotes a binary relation, also known as a property
Niklas Lindström: Yes, RDF may be pure conceptually... but it may require a Web developer to be a philosopher... [scribe assist by Manu Sporny]
Gregg Kellogg: the important thing is that we don't contradict RDF
Gregg Kellogg: text is a syntactic thing; literal is a model thing
... it might be worth updating the document with an issue marker about this
Markus Lanthaler: I'll rewrite it and put the proposing change into the issue marker
Manu Sporny: raised by dave lehn: The "External Contexts" section briefly mentions nested contexts.
... seems out of place and could perhaps use it's own named spec section
Gregg Kellogg: I agree that we need to keep nested contexts distinct
Manu Sporny: but contexts within contexts adds complexity
Manu Sporny: do we call contexts within a part of a document "scoped"?
Gregg Kellogg: an author may nest contexts within subject [sic] definitions
Manu Sporny: change that to scoped?
Gregg Kellogg: an author may include contexs within node definitions to accomplish a scoped context
PROPOSAL: Change the 'nest'ed terminology to 'scope'ed when referring to @contexts that exist inside of JSON objects.
Gregg Kellogg: +1
Niklas Lindström: +1
Manu Sporny: +1
François Daoust: +1
Markus Lanthaler: +1
RESOLUTION: Change the 'nest'ed terminology to 'scope'ed when referring to @contexts that exist inside of JSON objects.
Markus Lanthaler: We should also split the description of "scoped" contexts into it's own sub-section in the advanced section. [scribe assist by Manu Sporny]
Manu Sporny: +1
Topic: ISSUE-122: Allow declaring `@container` on `@type`
Niklas Lindström: What about adding a declarative syntax to the @context? "@container": "@set"? [scribe assist by Manu Sporny]
Manu Sporny: I'm not too fond of the idea. [scribe assist by Manu Sporny]
Discussion on pros/cons of flag for "always set" or e.g. @set: true or @container: @set in top-level of @context
François Daoust: is this an all-or-nothing for having values within arrays in compact form?
Manu Sporny: the in-between is having @set on every term, except for @type where we cannot do that
Gregg Kellogg: the alternative is to allow @container: @set in the context and @container: false to override that
Markus Lanthaler: I think the point is that you are either dealing w/ everything as optimized, or everything as an array - that's what the flag is for. [scribe assist by Manu Sporny]
Niklas Lindström: I'm wavering on this because I've seen cases where most of the data should be in sets... but there are also a bunch of properties that are functional properties -dct:identifier, dct:publisher, etc. [scribe assist by Manu Sporny]
François Daoust: [OK, I had somehow missed the issue was restricted to @type. I am in favor of an option flag to "compact()"]
Niklas Lindström: The needs for compaction are so specific for compaction that we can't address them all at this point. [scribe assist by Manu Sporny]
Manu Sporny: Would you rather not put the flag in there? [scribe assist by Manu Sporny]
Niklas Lindström: I'm fine w/ a flag at this point. [scribe assist by Manu Sporny]
PROPOSAL: Add a flag to the .compact() and .frame() algorithms that turns off optimization of arrays with single items in them to single values in the output.
Manu Sporny: +1
Niklas Lindström: +1
Markus Lanthaler: +1
Gregg Kellogg: +0.5
François Daoust: +0.5
RESOLUTION: Add a flag to the .compact() and .frame() algorithms that turns off optimization of arrays with single items in them to single values in the output.