Disambiguate uses of @type #77
Comments
|
This issue was discussed in a meeting.
View the transcriptIvan Herman: can @container be used with @type to separate string, dates, etc?… if so that is again an argument to deconflate all the meanings of @container Gregg Kellogg: might make sense but isn’t very useful … the datatype for all variations would be rdf:HTML, so you wouldn’t be able to also work by languages Ivan Herman: right. but even gkellogg had to think about whether you can use @type with @container, which tells us that we need to simplify … a container-mapping for @dataype — it’s not clear whether it would be useful Rob Sanderson: if rdf:Literal is the datatype… … if you had some HTML, some strings, maybe you can sort it out then Ivan Herman: so mapping via datatype is questionable Gregg Kellogg: I understand the proposal to be a new keyword @datatype to be used in contexts to signal datatypes, as @type does today … letting us mark that usage of @type as obsolete Ivan Herman: even today, you could use it via aliasing. Gregg Kellogg: compaction wouldn’t do what you want if you did that Ivan Herman: we have an example from Publishing WG where the alias would be useful, and round tripping not necessary Proposed resolution: add @datatype for use with value nodes that would be a synonym only in those situations for @type (Rob Sanderson) Rob Sanderson: +1 Ivan Herman: +1 Adam Soroka: +1 Harold Solbrig: +0 Simon Steyskal: +1 Gregg Kellogg: +0.5 Adam Soroka: Assuming bigbluehat is +1 Resolution #2: add @datatype for use with value nodes that would be a synonym only in those situations for @type |
You'll have to expand on this @iherman. I'm not sure why the JSON-LD in the Publishing WG's current spec should be any less round-trip-able than any other JSON-LD. Wiley's use of JSON-LD is part of a wider internal and external RDF-based ecosystem, so it'd be terrible to have an alias gum up the gears. Additionally, I'm not sure As in: {
"@value": "<strong>markup!</strong>",
"@datatype": "rdf:HTML"
}doesn't seem any clearer than: {
"@value": "<strong>markup!</strong>",
"@type": "rdf:HTML"
}and ultimately means someone somewhere will try to write: {
"@datatype": "Organization",
"name": "GitHub"
}which, if I understand the proposal (i.e. "synonym only in those situations") would fail...but for reasons unclear to the person writing the JSON. I'd actually have been 👎 on this had I been on the call. I'm just not sure what value this new bit of syntax is bringing vs. the confusion risk to folks typing JSON. Sorry folks... |
|
The behaviour of It can be disputed whether adding an alias for As for publishers: you may be right. But the feeling I have is that an overwhelming majority of user agents (including schema.org in this sense) do not do round tripping. They just consume the data, convert it into, say, triples, and take it from there. I may be wrong with my assessment. |
|
What we're specifically addressing with this issue is the variation between "node type" and "value type" as described in this note and it's following example: https://w3c.github.io/json-ld-syntax/#h-note-12 We should keep in mind that the "value type" construction is actually quite rare in data "in the wild" and frequently abstracted away via the Also, we've made RDF round tripping the reason for not adding certain requested features, so using it now as something people "do not do" seems dangerous--especially since it's something Wiley specifically does with our JSON-LD data. Regardless, introducing an alias that causes processing confusion in the hopes that it's somehow clearer than the existing rare contextual use of the |
|
I disagree. Value nodes occur in every JSON-LD document. The fact that the { I don't follow the round tripping issue. Is it that it would be indeterminate whether the original JSON used To me, we have seen the results of this conflation over and over again with the various issues that have been raised around type coercion for classes rather than datatypes. I don't think there's any "somehow" about it -- the proposal that |
|
The origin story as uncovered from history by @gkellogg: https://json-ld.org/minutes/2011-10-18/#topic-2 |
|
This issue was discussed in a meeting.
View the transcript3.1. @type / @datatypeRob Sanderson: link: #77 Rob Sanderson: two issue that came up as being particularly interesting. … we should focus on them and try to come to some consensus Rob Sanderson: related to issue 31 and the feeling at the time was that the overloading of @type was confusing … we proposed to add a new way in 1.1 to distinguish a datatype … that would clear up some of the confusion … decided to use @datatype but need to discuss more … ivan and I are on the pro side of @datatype. Ben is against it. Gregg Kellogg: I have mixed opinions. If we had thought about this originally it would have made sense but we did not. Now we need to consider backwards compatibility … creating an alias of datatype to @datatype might help … we would lose the @dataype alias with expansion … just keep in mind that it will disappear with any transformation Rob Sanderson: Example today: {"@type": "foaf:Person", "foaf:age": {"@value": "42", "@type": "xsd:integer"}} Rob Sanderson: Proposed additional synonymous construct: {"@type": "foaf:Person", "foaf:age": {"@value": "42", "@datatype": "xsd:integer"}} Pierre-Antoine Champin: I assumed that @type usage had been talked about in the 1.0 dev. Wanted to hear why the decision was made to not split the hair. Gregg Kellogg: https://json-ld.org/minutes/2011-10-18/#topic-2 Gregg Kellogg: there was an explosion of keywords back in the day and we determined that some were redundant or very similar. we did have an @datatype and decided to merge them back in 2011. … this was decided prior to the close alignment to RDF Gregg Kellogg: https://json-ld.org/minutes/2011-12-13/#resolution-5 Gregg Kellogg: Quote from Manu - “what convinced me most was Markus’ argument that we should make it as simple as possible without losing functionality” Gregg Kellogg: json-ld/json-ld.org#31 Gregg Kellogg: From lanthaler - “I don’t think we can argue that we reduce the amount of invalid data that is created by having two different keywords. I’d argue that we increase the problem because people might put @datatype in the wrong place vs. @type.” Benjamin Young: which camps are we making it easier or harder for. it is rare to see this type of thing in the actual data. hearing what Gregg would have to do to make it works seems a bit too much to ask. The type coercion is valid but might be a fringe use case … concerned about the ramifications of doing this David Newbury: when trying to learn JSON-ld and learning that @type means 2 different things. Long time to wrap my head around using the wrong keyword with different meaning. Rob Sanderson: I had the same experience. In the IIIF world we had 5 editors and we were trying to use type coercion on classes but we found that it did not work … also confuses a vendor we are working with … no evidence that it is more confusing to separate them … you could compact and expand to create valid JSON-ld. round-tripping seems like not an issue. Benjamin Young: I agree that @type is confusing. What I am concerned about is if adding @datatype makes it any more clear … very robust explanation would help … this could create a new set of confusion Ivan Herman: one thing we need to remind ourselves is that our only requirement is that a valid 1.0 is valid 1.1 … round tripping in not really an issue … what happens in 1.1 with processing the data. … pure JSON users will likely have issue in general. Diff between classes and literals are already somewhat confusing. … separating @type and @datatype makes it clear that there is a distinction Pierre-Antoine Champin: could we specify that @type is used for resources, and @datatype is used for literals, but that @type can be used as an alias for @datatype Gregg Kellogg: we could make the move to use @datatype and allow for @type for backwards compatibility. The issue is the processor, which is currently either 1.0 or 1.1 mode. … do we change the default processor to 1.1 and require a way to switch to change to 1.0 Benjamin Young: +1 to what Gregg was saying. The versioning is a problem outside of the problem of what is better solution. There is a risk whenever you change things. … what is the impact on consumers of JSON-ld when the consumers are consuming pure JSON not Graph data Rob Sanderson: sounds like there are 4 or 5 folks that are in favor and 1 against and 1 neutral (leaning against). The arguments against are significant (the 1.0 vs 1.1 processing issue) … If Ben and Gregg come up with a clear/complete definition of @type and a further rewording around type coercion. Then we can read them over, assess the definition and see if the text of the spec is clear enough to explain what the difference is and how to implement it … we can then decide if the documentation is sufficient or if we need to further consider splitting them Gregg Kellogg: https://www.w3.org/TR/json-ld11/#syntax-tokens-and-keywords Gregg Kellogg: is the current wording not clear enough? what are you looking for? … could we raise issue about the current documentation about what is not clear enough Rob Sanderson: nodes are meaningless to people with RDF hats on. Gregg Kellogg: are you looking for the current docs to be improved or for something new Rob Sanderson: 1.7 is fine. 4.2.1 needs more clarity … it is not a technical issue it is a learning/implementation issue … 4.2 is the problem … splitting out @type into how to use for Classes and for Literals Gregg Kellogg: what about further definition of other keywords Rob Sanderson: a section in 9 about keywords and gives full definition. Benjamin Young: more than happy to help rewording. confusion between Value instead of Literal. Ivan Herman: we should make is more explicit that there is very clear distinction between classes and literals in JSON-ld Rob Sanderson: +1 to Ivan David Newbury: need a JSON person primer Proposed resolution: bigbluehat & gkellogg to come up with rewording for 4.2, and new section for 9 for keywords, for review as to whether this will solve confusion without technical change (Rob Sanderson) Rob Sanderson: +1 Jeff Mixter: +1 Ivan Herman: +1 Benjamin Young: +1 (noting it might include more revising elsewhere) Gregg Kellogg: +1 David Newbury: +1 Pierre-Antoine Champin: +1 Resolution #2: bigbluehat & gkellogg to come up with rewording for 4.2, and new section for 9 for keywords, for review as to whether this will solve confusion without technical change |
I'm glad this is where things are now. The whole move to Specifically, we knew that not having |
I don't know that I'm the target audience but the major confusion for me that pushed JSON-LD from i'll-grok-the-spec to i'll-fiddle-around-until-it-works was the fact that @type had so many different uses. Sure they don't appear in the same place so there's technically no conflict but minification of the vocabulary has real cognitive costs. |
You are definitely not the target audience. You know too much. :)
It has real cognitive costs for people that understand the technology at depth. There are always going to be far fewer of those people (experts) than there are of people that just want to copy-paste-modify examples (novices). JSON-LD, by and large, is designed for novices that don't need to know. In fact, we try really hard to make it such that they don't need to know details for a long time... such as RDF making a distinction between the type of a resource and the type of a literal. The former is In any case, if you know that there is a difference between a resource type and a literal type, then you already know too much and you're already probably capable of really grokking how JSON-LD maps to RDF. To put it another way, if JSON-LD expands to expose Web developers to all of RDF's features, then we will have failed. |
|
I originally voted for this change, but I'm realizing that there is more going on here than I understood. Just some general thoughts from listening to the discussion: I understand us to have several target audiences (and none of us, I guess, are well representative of any of them 😁 ), but for this issue, one obvious division is between people going RDF->JSON and those going the other way (who, I would think, outnumber the former). Another is between context authors and people who use someone else's context (I would expect many more of the latter, at least for some time to come). RDF->JSON folks will start out with the distinction between Some of the debate I'm hearing is about whether we do well for the people writing contexts to make the distinction very obvious via keywords (and thus hopefully avoid the confusions around type coercion which @azaroth42 has noticed and which I have also seen) or whether, for people who don't need this distinction in their own systems, we do ill to make them notice it for this one task. JSON, as I understand it, doesn't have a first-class notion like I realize that we are well down the road on this question, but one principle I would offer is that whatever we do should, as much as possible, make the JSON first-class types map more cleanly and simply. Ideally, this would be both in instances and contexts. It would be nice to be able to say that a context author should use features A and B to to map any JSON first-class type (whether it be a string, a number, or an object) and features X and Y to map API-specific types (which we secretly know are much more likely to become |
To me this seems a bit exaggerated. If JSON-LD requires Web developers to be exposed to all of RDF's features, we have failed. But allowing them access to those features in as comfortable a way as possible, without requiring devs to be aware of them unless/until necessary, seems like a (difficult but) appropriate goal. |
History is littered with groups of standardization bodies, composed of individuals that are incredibly smart and well meaning, that have ruined entire languages by thinking that they have kept the ergonomics of a language approachable. I think that you are underestimating how difficult it is to achieve the goal you stated once the language becomes a swiss army knife. JSON-LD was never intended to become a swiss army knife. :) |
I don't see this as an RDF issue. As a JSON user, I find it confusing that the same keyword is used for structure types and scalar types. Structure type says that an object gets a |
|
@ericprud wrote:
Yeah, man... this proves my point. You're way more knowledgeable than 99.99% of the people out there that use JSON. I mean, let's be honest, you're easily like top 25 on the planet when it comes to understanding all of this stuff. :) I don't expect 99.99% of JSON developers to need to use |
|
Flatterer! Every JSON user knows the difference between an object |
|
I'm a little troubled by how much comment on this ticket aims to speak for "JSON users" or "JSON developers". That seems a bit "low-res" to me. There are many different overlapping categories of JSON users. Someone trying to stick a stanza of SEO metadata in their home-hosted blog isn't the same as someone trying to consume a semantically-enabled JSON API isn't the same as @danbri's folks isn't the same as someone trying to write a context for their long-established API, and none of these activities look all that much like WoT. It may be that I worry too much about this sort of "representational" issue, but I'd appreciate it if, for this issue, we could all be as precise as possible when we discuss user needs or knowledge and specify as much as possible beyond "JSON users" or "JSON devs"... |
My perspective is one of lowest common denominator and the biggest user community that we have right now, and that's schema.org. I always think about how a feature is going to impact them, and if there is a non-trivial possibility that it will be negative, then it's a strike against the feature in my mind. Everyone else is secondary because they usually have the motivation and background to dig in and try to really understand at depth. I'm not worried about the people at the "expert" level of the spectrum, because they will be able to figure it out. I do worry about the folks in the middle, who know just enough to really get them into trouble... especially if there is a large selection of footguns to pick from that are just barely under the surface of JSON-LD. ... but all this is going to be vague and theoretical until we have a specific feature to talk about. |
|
I understood us to be talking about the feature discussed in this ticket ( |
Yes, which means we're debating a feature that the vast majority of people using JSON-LD (that I think the language is primarily designed for) will never see or touch. It's solving a problem that they don't have... and introducing it may have the unintended consequence that @BigBlueHat raised above -- higher cognitive load when learning the language AND misuse of |
|
The vast majority of people using JSON-LD will never write their own context, but I'm sure you agree that we don't want to put any feature that is useful mostly for context-authors out of scope for discussion. |
Yes, agreed... especially if that feature helps make things simpler for the vast majority of people authoring JSON-LD content (even if they don't really know that that's what they're doing). |
|
I think further discussion is somewhat muted by my interpretation of the recent WG discussion and the content of PR #92. Although the original discussion was about introducing
After a couple of small changes, I intend to merge that PR without closing the issue, and we'll see where we are after that. |
|
Regarding what constituency JSON-LD serves, in my opinion, the landscape has changed markedly since the original recommendation was made: JSON-LD is a fundamental part of the web, and we need to consider the experience of those communities. JSON-LD is also seeing substantial new deployment opportunities, where the appeal is definitely that it is JSON, but there is a stronger need to use rich semantic expressiveness (@ajs6f noted WoT, but also Publishing, and Verifiable Claims). I believe that it's necessary to express pretty most all of RDF in JSON-LD, and the specs need to make this clear. In fact, since adding support for lists of lists, we can pretty much do that. I don't think that the Syntax document should be weighed down with these bits, but they do require introduction, examples, and the normative grammar to describe them. JSON-LD has been an enormous success, and we don't want to screw that up, but we also have a somewhat different value-proposition now, and groups formerly foreign to the idea have, in fact, become more educated (witness the SEO community's work in adopting JSON-LD and semantics). Of course there remain JSON constituents that are not (yet) on board with JSON-LD, but recent discussions at the TAG indicate a broad appreciation for what JSON-LD may be able to do for the web platform. |
|
Pulled #92 which addresses this issue. Requires WG action to close the issue. |
|
This issue was discussed in a meeting.
View the transcriptGregg Kellogg: issue 56 - this was looking for examples to indicate unexpected behavior when type is a vocab… i think ball was in Ivan’s court whether the examples were sufficient … we are not closing the issue until after the PR, so question is whether we are ready to close … we added 2 examples … next issue is 77, disambiguate uses of @type … Webex seems to have some problems with this meeting, especially if changing focus on my computer … we discussed adding @datatype, instead decided to add text around different uses of @type … are people satisfied with wording? Gregg Kellogg: use of @none regarding language … in seeming conflict with requirement that language has to be string, @none didn’t specify … fixed that wording making clear that @none has to be a string Benjamin Young: these are tagged proposed closing … we need to decide if ready to close Adam Soroka: I wanted to mention the @datatype issue - I’m okay with this, but we may need a gitHub tag for whenever issues about @type comes up … this will be a way to verify that spec wording update is enough to minimize confusion Gregg Kellogg: w3c/json-ld-wg#24 Gregg Kellogg: I did raise issue 24 about surfacing the minutes on this topic like we did in Community Group … could we do this? … was useful in community group Ivan Herman: minutes cleanup is done by me, and summarizing each meeting may not be a good idea Gregg Kellogg: there is a scribe tool that builds summaries and indexes automatically Benjamin Young: it works on issues and action lists at top/bottom of each meeting minutes Gregg Kellogg: the good thing is it aggregates all minutes on each issue Benjamin Young: I will take an action to investigate to see if we can build index of minutes by issue … I think this is a good idea Gregg Kellogg: will work with bigbluehat on this since I worked on CG Benjamin Young: can we close these 3 issues … 56, 77 and 102 ? Ivan Herman: can we do a resolution to close these 3 issues? Proposed resolution: close issues 56, 77, and 102 as having been addressed by recent merges (Benjamin Young) Ivan Herman: +1 Gregg Kellogg: +1 Tim Cole: +1 Benjamin Young: +1 David Newbury: +1 Pierre-Antoine Champin: +1 Resolution #1: close issues 56, 77, and 102 as having been addressed by recent merges |
ghost
removed
the
Related to json-ld-api#33, we discussed on 2018-10-05 WG call the distinction between
@typeas a baked in alias forrdf:type, and@typeas a function of the syntax for specifying the data type of the JSON object (resource vs literal, and type of literal), via the context.There was general agreement that this was a common source of confusion, and could be ameliorated for expansion by introducing an alias (for example
@datatype) but that this would add to confusion in compaction, as it would replace@typeeverywhere. A more robust change would require a change to the specification to allow either@typeor@datatypeas the way to specify the data type, however that is a significant addition that should be considered in detail.Further, one might introduce
type:rdf:typein a context, rather than use the more magical@type. This approach would also impact the specifications, but would follow from the rejection of the@labelsyntactic sugar in #6.The text was updated successfully, but these errors were encountered: