Skip to content
  • Categories
  • Recent
  • Popular
Skins
  • Light
  • Cerulean
  • Cosmo
  • Flatly
  • Journal
  • Litera
  • Lumen
  • Lux
  • Materia
  • Minty
  • Morph
  • Pulse
  • Sandstone
  • Simplex
  • Sketchy
  • Spacelab
  • United
  • Yeti
  • Zephyr
  • Dark
  • Cyborg
  • Darkly
  • Quartz
  • Slate
  • Solar
  • Superhero
  • Vapor

  • Default (No Skin)
  • No Skin
Collapse

NodeBB-ActivityPub Bridge Test Instance

  1. Home
  2. Categories
  3. Uncategorized
  4. i'm not 100% sure about this but i am starting to think that the way #jsonld context declarations propagate by default is generally an anti-pattern

i'm not 100% sure about this but i am starting to think that the way #jsonld context declarations propagate by default is generally an anti-pattern

Scheduled Pinned Locked Moved Uncategorized
jsonld
106 Posts 3 Posters 0 Views
  • Oldest to Newest
  • Newest to Oldest
  • Most Votes
Reply
  • Reply as topic
Log in to reply
This topic has been deleted. Only users with topic management privileges can see it.
  • trwnh@mastodon.socialT trwnh@mastodon.social

    @jens really, the challenge is that people produce all kinds of "bad JSON", because of poor data models, lots of indirection, etc. -- it can be complex to unravel all those bad practices and get the true simple meaning out of the soup.

    jens@social.finkhaeuser.deJ This user is from outside of this forum
    jens@social.finkhaeuser.deJ This user is from outside of this forum
    jens@social.finkhaeuser.de
    wrote last edited by
    #25

    @trwnh Sure. But you're not going to avoid that. People will always be people.

    You need a way to keep one bad data model from not interfering with another. Anything else becomes tilting at windmills IMHO.

    trwnh@mastodon.socialT 1 Reply Last reply
    0
    • jens@social.finkhaeuser.deJ jens@social.finkhaeuser.de

      @trwnh Namespaces don't solve this? You lost me there, sorry. Could you explain that?

      trwnh@mastodon.socialT This user is from outside of this forum
      trwnh@mastodon.socialT This user is from outside of this forum
      trwnh@mastodon.social
      wrote last edited by
      #26

      @jens namespaces are only a solution for people willing to deal with namespaces. there are JSON consumers who don't understand namespacing at all. the JSONLD context qualifies a term like `actor` to be as:actor or schema:actor or whatever, but the naive JSON consumer is looking for the literal key `actor` *without expanding to the full IRI*.

      1 Reply Last reply
      0
      • jens@social.finkhaeuser.deJ jens@social.finkhaeuser.de

        @trwnh Again, lost me. XML namespaces don't carry semantic information how?

        I *think* I know what you mean, but if so, I might disagree. Can't be sure, though 🤷‍♂️

        trwnh@mastodon.socialT This user is from outside of this forum
        trwnh@mastodon.socialT This user is from outside of this forum
        trwnh@mastodon.social
        wrote last edited by
        #27

        @jens XML namespaces are a simple prefix mechanism, just like JSONLD can be used as a simple prefix mechanism if you only use simple term definitions to define prefixes

        but the full context is more than that. you take `actor` and you can expand to `http://schema.org/actor` and that's where namespaces stop. you still need to know whether the value is a string literal or a reference to something else on the graph.

        jens@social.finkhaeuser.deJ 1 Reply Last reply
        0
        • trwnh@mastodon.socialT trwnh@mastodon.social

          @jens XML namespaces are a simple prefix mechanism, just like JSONLD can be used as a simple prefix mechanism if you only use simple term definitions to define prefixes

          but the full context is more than that. you take `actor` and you can expand to `http://schema.org/actor` and that's where namespaces stop. you still need to know whether the value is a string literal or a reference to something else on the graph.

          jens@social.finkhaeuser.deJ This user is from outside of this forum
          jens@social.finkhaeuser.deJ This user is from outside of this forum
          jens@social.finkhaeuser.de
          wrote last edited by
          #28

          @trwnh Correct.

          But a naive consumer can (and should) simply not process namespaces they don't understand.

          I think you may need to let go a little of what namespaces mean in JSON-LD, and consider what they mean elsewhere.

          trwnh@mastodon.socialT 1 Reply Last reply
          0
          • jens@social.finkhaeuser.deJ jens@social.finkhaeuser.de

            @trwnh Sure. But you're not going to avoid that. People will always be people.

            You need a way to keep one bad data model from not interfering with another. Anything else becomes tilting at windmills IMHO.

            trwnh@mastodon.socialT This user is from outside of this forum
            trwnh@mastodon.socialT This user is from outside of this forum
            trwnh@mastodon.social
            wrote last edited by
            #29

            @jens that's the goal of the thread 🙂

            the LD agent sees the graph as a graph, but the JSON agent sees the graph as a JSON document. it might understand that a certain value is actually a reference, but then how can it dereference?

            the LD agent does a graph merge. no problems.

            the JSON agent fetches a JSON document and naively sets that JSON object as the value of the property to be expanded. oops, problems! you might have just accidentally redefined a term from the parent document!

            jens@social.finkhaeuser.deJ 1 Reply Last reply
            0
            • trwnh@mastodon.socialT trwnh@mastodon.social

              @jens that's the goal of the thread 🙂

              the LD agent sees the graph as a graph, but the JSON agent sees the graph as a JSON document. it might understand that a certain value is actually a reference, but then how can it dereference?

              the LD agent does a graph merge. no problems.

              the JSON agent fetches a JSON document and naively sets that JSON object as the value of the property to be expanded. oops, problems! you might have just accidentally redefined a term from the parent document!

              jens@social.finkhaeuser.deJ This user is from outside of this forum
              jens@social.finkhaeuser.deJ This user is from outside of this forum
              jens@social.finkhaeuser.de
              wrote last edited by
              #30

              @trwnh What I mean is, don't do LD. Problem solved.

              trwnh@mastodon.socialT 1 Reply Last reply
              0
              • jens@social.finkhaeuser.deJ jens@social.finkhaeuser.de

                @trwnh Correct.

                But a naive consumer can (and should) simply not process namespaces they don't understand.

                I think you may need to let go a little of what namespaces mean in JSON-LD, and consider what they mean elsewhere.

                trwnh@mastodon.socialT This user is from outside of this forum
                trwnh@mastodon.socialT This user is from outside of this forum
                trwnh@mastodon.social
                wrote last edited by
                #31

                @jens the problem is that terms conflict, and the naive consumer isn't "simply not process[ing] namespaces they don't understand" -- they straight up don't understand the concept of namespacing.

                this is a problem because they will then perform data manipulations that cause all kinds of semantic hell, completely unaware that they are doing anything wrong.

                they don't understand that `actor` can mean two different things. for all they know, `actor` ALWAYS means as:actor, even when it doesn't!

                trwnh@mastodon.socialT jens@social.finkhaeuser.deJ 2 Replies Last reply
                0
                • trwnh@mastodon.socialT trwnh@mastodon.social

                  @jens the problem is that terms conflict, and the naive consumer isn't "simply not process[ing] namespaces they don't understand" -- they straight up don't understand the concept of namespacing.

                  this is a problem because they will then perform data manipulations that cause all kinds of semantic hell, completely unaware that they are doing anything wrong.

                  they don't understand that `actor` can mean two different things. for all they know, `actor` ALWAYS means as:actor, even when it doesn't!

                  trwnh@mastodon.socialT This user is from outside of this forum
                  trwnh@mastodon.socialT This user is from outside of this forum
                  trwnh@mastodon.social
                  wrote last edited by
                  #32

                  @jens i need to stress that the JSON agent is, in this case, creating the problem where there wasn't a problem before.

                  as two separate JSON documents, all is fine and dandy.

                  it's when you naively merge the two JSON documents that you might accidentally produce a resulting document that has errors. this merging is foundational for Web use-cases.

                  jens@social.finkhaeuser.deJ 1 Reply Last reply
                  0
                  • trwnh@mastodon.socialT trwnh@mastodon.social

                    @jens the problem is that terms conflict, and the naive consumer isn't "simply not process[ing] namespaces they don't understand" -- they straight up don't understand the concept of namespacing.

                    this is a problem because they will then perform data manipulations that cause all kinds of semantic hell, completely unaware that they are doing anything wrong.

                    they don't understand that `actor` can mean two different things. for all they know, `actor` ALWAYS means as:actor, even when it doesn't!

                    jens@social.finkhaeuser.deJ This user is from outside of this forum
                    jens@social.finkhaeuser.deJ This user is from outside of this forum
                    jens@social.finkhaeuser.de
                    wrote last edited by
                    #33

                    @trwnh You're still in LD headspace.

                    In basic namespace headspace, "actor" doesn't exist. It's either e.g. "as:actor", which the consumer may understand (should in the context of AS), or it's "foo:actor", which the consumer doesn't understand and doesn't process.

                    Keep in mind that MIME has existed for decades, and was used in Email *and* HTTP (Until the QUIC crowd forked it [TL;DR]) with this simple a scheme for headers, and there was no semantic ambiguity here.

                    trwnh@mastodon.socialT 1 Reply Last reply
                    0
                    • jens@social.finkhaeuser.deJ jens@social.finkhaeuser.de

                      @trwnh What I mean is, don't do LD. Problem solved.

                      trwnh@mastodon.socialT This user is from outside of this forum
                      trwnh@mastodon.socialT This user is from outside of this forum
                      trwnh@mastodon.social
                      wrote last edited by
                      #34

                      @jens no, i want to do LD because i want to be able to fetch documents over the Web and reason about things. the LD agent knows what it's doing and doesn't cause problems.

                      1 Reply Last reply
                      0
                      • trwnh@mastodon.socialT trwnh@mastodon.social

                        @jens i need to stress that the JSON agent is, in this case, creating the problem where there wasn't a problem before.

                        as two separate JSON documents, all is fine and dandy.

                        it's when you naively merge the two JSON documents that you might accidentally produce a resulting document that has errors. this merging is foundational for Web use-cases.

                        jens@social.finkhaeuser.deJ This user is from outside of this forum
                        jens@social.finkhaeuser.deJ This user is from outside of this forum
                        jens@social.finkhaeuser.de
                        wrote last edited by
                        #35

                        @trwnh See, this I disagree with. I think rather that JSON-LD didn't sufficiently consider that pure JSON processors would process their documents. But that is not a productive squabble to have, so I won't die on that hill 🤣😊

                        trwnh@mastodon.socialT 1 Reply Last reply
                        0
                        • jens@social.finkhaeuser.deJ jens@social.finkhaeuser.de

                          @trwnh You're still in LD headspace.

                          In basic namespace headspace, "actor" doesn't exist. It's either e.g. "as:actor", which the consumer may understand (should in the context of AS), or it's "foo:actor", which the consumer doesn't understand and doesn't process.

                          Keep in mind that MIME has existed for decades, and was used in Email *and* HTTP (Until the QUIC crowd forked it [TL;DR]) with this simple a scheme for headers, and there was no semantic ambiguity here.

                          trwnh@mastodon.socialT This user is from outside of this forum
                          trwnh@mastodon.socialT This user is from outside of this forum
                          trwnh@mastodon.social
                          wrote last edited by
                          #36

                          @jens but it's *not* literally `foo:actor` in the serialized JSON document -- it's `actor`. just that two different documents both use `actor` in different ways... and context propagation means that an earlier definition still applies until redefined. which you can't do for protected terms.

                          things like MIME and HTTP headers work because of centralized IANA registries acting as the namespace. you can to some degree think of a MIME type as having its own implicit context via specified semantics.

                          1 Reply Last reply
                          0
                          • jens@social.finkhaeuser.deJ jens@social.finkhaeuser.de

                            @trwnh See, this I disagree with. I think rather that JSON-LD didn't sufficiently consider that pure JSON processors would process their documents. But that is not a productive squabble to have, so I won't die on that hill 🤣😊

                            trwnh@mastodon.socialT This user is from outside of this forum
                            trwnh@mastodon.socialT This user is from outside of this forum
                            trwnh@mastodon.social
                            wrote last edited by
                            #37

                            @jens JSON processors need to be careful that they are processing their document in a way that doesn't shred the underlying semantics, no?

                            like, the root cause of the problem is that there are multiple documents, and it matters how you dereference a reference. you have semantic consistency within each document, but you can't just smush the two documents together any which way you please and expect others to understand what you did. you'd be changing semantics for everyone else.

                            trwnh@mastodon.socialT 1 Reply Last reply
                            0
                            • trwnh@mastodon.socialT trwnh@mastodon.social

                              @jens JSON processors need to be careful that they are processing their document in a way that doesn't shred the underlying semantics, no?

                              like, the root cause of the problem is that there are multiple documents, and it matters how you dereference a reference. you have semantic consistency within each document, but you can't just smush the two documents together any which way you please and expect others to understand what you did. you'd be changing semantics for everyone else.

                              trwnh@mastodon.socialT This user is from outside of this forum
                              trwnh@mastodon.socialT This user is from outside of this forum
                              trwnh@mastodon.social
                              wrote last edited by
                              #38

                              @jens think of it as "how can a JSON processor combine two valid documents with different semantics and produce another valid document without altering the semantics"

                              if you don't take care to preserve the semantics, you will get a syntactically valid combined JSON document but there will be semantic confusion because the semantics weren't preserved. the literal key `actor` means different things in different parts of the combined document.

                              would an example help? i can try to whip one up rn...

                              jens@social.finkhaeuser.deJ 1 Reply Last reply
                              0
                              • trwnh@mastodon.socialT trwnh@mastodon.social

                                @jens think of it as "how can a JSON processor combine two valid documents with different semantics and produce another valid document without altering the semantics"

                                if you don't take care to preserve the semantics, you will get a syntactically valid combined JSON document but there will be semantic confusion because the semantics weren't preserved. the literal key `actor` means different things in different parts of the combined document.

                                would an example help? i can try to whip one up rn...

                                jens@social.finkhaeuser.deJ This user is from outside of this forum
                                jens@social.finkhaeuser.deJ This user is from outside of this forum
                                jens@social.finkhaeuser.de
                                wrote last edited by
                                #39

                                @trwnh No, I understand the problem. I think you're assuming that creating a combined document necessitates pulling more deeply nested keys into an object closer to the root. This is not an assumption I'm making.

                                Put differently, a "foo:bar" in the root object isn't and shouldn't be the same as a "foo:bar" underneath a "baz:quux" key. The "baz" namespace determines what "quux" means, and the definition of "quux" determines the semantics of finding a "foo:bar" underneath it. It may refer to a...

                                jens@social.finkhaeuser.deJ 1 Reply Last reply
                                0
                                • jens@social.finkhaeuser.deJ jens@social.finkhaeuser.de

                                  @trwnh No, I understand the problem. I think you're assuming that creating a combined document necessitates pulling more deeply nested keys into an object closer to the root. This is not an assumption I'm making.

                                  Put differently, a "foo:bar" in the root object isn't and shouldn't be the same as a "foo:bar" underneath a "baz:quux" key. The "baz" namespace determines what "quux" means, and the definition of "quux" determines the semantics of finding a "foo:bar" underneath it. It may refer to a...

                                  jens@social.finkhaeuser.deJ This user is from outside of this forum
                                  jens@social.finkhaeuser.deJ This user is from outside of this forum
                                  jens@social.finkhaeuser.de
                                  wrote last edited by
                                  #40

                                  @trwnh ... more general definition about the key, sure, but the existence under another object determines the relationship.

                                  This isn't very LD like.

                                  You can avoid duplication still by supporting document internal JSON references, if you want. That does require the JSON processor to understand those, of course. You can do *more* than namespaces, sure.

                                  trwnh@mastodon.socialT 1 Reply Last reply
                                  0
                                  • trwnh@mastodon.socialT trwnh@mastodon.social

                                    one approach is to just say "well, plain JSON consumers should just stop being so naive". a valid approach, but not very robust!

                                    our goal is to preserve the semantic boundary between different resources but still allow merging those resources naively (as JSON objects rather than as #JSONLD graphs).

                                    instead of saying that a term will *always* mean the same thing in the entire document, we want to allow the same term to be used in different contexts across semantic boundaries (resources)...

                                    6/?

                                    nik@toot.teckids.orgN This user is from outside of this forum
                                    nik@toot.teckids.orgN This user is from outside of this forum
                                    nik@toot.teckids.org
                                    wrote last edited by
                                    #41

                                    @trwnh As I said: no. JSON-LD is not plain JSON, period. The terms used in one JSON-LD document are only ever valid in this one document. The document is the boundary, you cannot make any assumptions from one document for another one. It's true for all RDF sources, and even laid out explicitly in RDF Syntax and Abstract Concepts. That goes even further: Semantics of one document may change every time you read it (not applicable here, but please just never ignore that JSON-LD is RDF).

                                    trwnh@mastodon.socialT 1 Reply Last reply
                                    0
                                    • jens@social.finkhaeuser.deJ jens@social.finkhaeuser.de

                                      @trwnh ... more general definition about the key, sure, but the existence under another object determines the relationship.

                                      This isn't very LD like.

                                      You can avoid duplication still by supporting document internal JSON references, if you want. That does require the JSON processor to understand those, of course. You can do *more* than namespaces, sure.

                                      trwnh@mastodon.socialT This user is from outside of this forum
                                      trwnh@mastodon.socialT This user is from outside of this forum
                                      trwnh@mastodon.social
                                      wrote last edited by
                                      #42

                                      @jens

                                      > The "baz" namespace determines what "quux" means, and the definition of "quux" determines the semantics of finding a "foo:bar" underneath it

                                      ok, but how do you deal with a naive processor that doesn't know what any of this means?

                                      i am describing the case where you see this:

                                      <some activity> <has an actor> <me>.
                                      <some activity> <is a> <Like>.
                                      <some activity> <has an object> <ghostbusters>.

                                      then you dereference <ghostbusters> and get:

                                      <ghostbusters> <has an actor> <bill murray>.

                                      trwnh@mastodon.socialT 1 Reply Last reply
                                      0
                                      • trwnh@mastodon.socialT trwnh@mastodon.social

                                        @jens

                                        > The "baz" namespace determines what "quux" means, and the definition of "quux" determines the semantics of finding a "foo:bar" underneath it

                                        ok, but how do you deal with a naive processor that doesn't know what any of this means?

                                        i am describing the case where you see this:

                                        <some activity> <has an actor> <me>.
                                        <some activity> <is a> <Like>.
                                        <some activity> <has an object> <ghostbusters>.

                                        then you dereference <ghostbusters> and get:

                                        <ghostbusters> <has an actor> <bill murray>.

                                        trwnh@mastodon.socialT This user is from outside of this forum
                                        trwnh@mastodon.socialT This user is from outside of this forum
                                        trwnh@mastodon.social
                                        wrote last edited by
                                        #43

                                        @jens an aware agent can merge these two graphs while preserving context. <has an actor> in the first graph gets qualified with a prefix or namespace.

                                        an unaware agent doesn't know what they're doing. they just blindly copy <has an actor> without qualifying it at all. this is what introduces the issue.

                                        jens@social.finkhaeuser.deJ 1 Reply Last reply
                                        0
                                        • trwnh@mastodon.socialT trwnh@mastodon.social

                                          @jens an aware agent can merge these two graphs while preserving context. <has an actor> in the first graph gets qualified with a prefix or namespace.

                                          an unaware agent doesn't know what they're doing. they just blindly copy <has an actor> without qualifying it at all. this is what introduces the issue.

                                          jens@social.finkhaeuser.deJ This user is from outside of this forum
                                          jens@social.finkhaeuser.deJ This user is from outside of this forum
                                          jens@social.finkhaeuser.de
                                          wrote last edited by
                                          #44

                                          @trwnh What issue?

                                          The issue only exist if you insist on interpreting the merged document (! not knowledge graph!) as linked data.

                                          "has an object" isn't something JSON knows. JSON knows keys that point at values. Your value may be a reference, if you go that way, or it may be any other JSON.

                                          Perhaps the key is "hasObject". Perhaps it's "attachment". Either way, the path ".outer-key.actor" is different from ".actor", so whatever sits there as values doesn't have the same semantics.

                                          trwnh@mastodon.socialT 1 Reply Last reply
                                          0
                                          Reply
                                          • Reply as topic
                                          Log in to reply
                                          • Oldest to Newest
                                          • Newest to Oldest
                                          • Most Votes


                                          • Login

                                          • Login or register to search.
                                          Powered by NodeBB Contributors
                                          • First post
                                            Last post
                                          0
                                          • Categories
                                          • Recent
                                          • Popular