#1 json-ld context

Closed
opened 3 years ago by zPlus · 14 comments
zPlus commented 3 years ago

In ISSUES I think it's a better idea to define the context as

"@context": {
    "as": "https://www.w3.org/ns/activitystreams#",
    "rfv": "https://peers.community/ns/repo-fed-vocab#"
}

so the object becomes

{
  "@context": {
      "as": "https://www.w3.org/ns/activitystreams#",
      "rfv": "https://peers.community/ns/repo-fed-vocab#"
  },
  "as:type": "Create",
  "as:id": "https://notabug.org/fr33domlover/posts/595c1fd3-a0db-415c-a059-bf7ae99ecd3f",
  "as:to": "https://notabug.org/zPlus/freepost",
  "as:actor": "https://notabug.org/fr33domlover",
  "as:object": {
      "as:type": "rfv:Issue",
      "as:id": "https://notabug.org/zPlus/freepost/issues/217",
      "as:attributedTo": "https://notabug.org/fr33domlover",
      "as:to": "https://notabug.org/zPlus/freepost",
      "rfv:tracker": "https://notabug.org/zPlus/freepost",
      "rfv:issue-number": 217,
      "rfv:title": "Implement ActivityPub federation",
      "rfv:description": "What if Freepost becomes an AP server?",
      "rfv:creation-time": "2018-07-06 14:28:57"
    }
}
In [ISSUES](https://notabug.org/peers/repo-fed-vocab/src/master/ISSUE.md) I think it's a better idea to define the context as "@context": { "as": "https://www.w3.org/ns/activitystreams#", "rfv": "https://peers.community/ns/repo-fed-vocab#" } so the object becomes { "@context": { "as": "https://www.w3.org/ns/activitystreams#", "rfv": "https://peers.community/ns/repo-fed-vocab#" }, "as:type": "Create", "as:id": "https://notabug.org/fr33domlover/posts/595c1fd3-a0db-415c-a059-bf7ae99ecd3f", "as:to": "https://notabug.org/zPlus/freepost", "as:actor": "https://notabug.org/fr33domlover", "as:object": { "as:type": "rfv:Issue", "as:id": "https://notabug.org/zPlus/freepost/issues/217", "as:attributedTo": "https://notabug.org/fr33domlover", "as:to": "https://notabug.org/zPlus/freepost", "rfv:tracker": "https://notabug.org/zPlus/freepost", "rfv:issue-number": 217, "rfv:title": "Implement ActivityPub federation", "rfv:description": "What if Freepost becomes an AP server?", "rfv:creation-time": "2018-07-06 14:28:57" } }
fr33domlover commented 3 years ago
Collaborator

We can't define the context that way, because the w3 URL is not just a prefix. It's an actual file that the JSON-LD processor downloads and parses. So it must be listed as a remote context. In addition, I think it's best to let the AS2 properties continue to be used without prefix, so that all existing software that can handle extra context/prefix, even if it doesn't handle full JSON-LD, can still parse these objects and recognize the parts that are from AS2 (such as understanding that this is a Create activity with a given ID and a given recipient and so on).

We can't define the context that way, because the w3 URL is not just a prefix. It's an actual file that the JSON-LD processor downloads and parses. So it must be listed as a remote context. In addition, I think it's best to let the AS2 properties continue to be used without prefix, so that all existing software that can handle extra context/prefix, even if it doesn't handle full JSON-LD, can still parse these objects and recognize the parts that are from AS2 (such as understanding that this is a Create activity with a given ID and a given recipient and so on).
fr33domlover commented 3 years ago
Collaborator

(Something we could do that would keep the use of AS2 terms the same is to entirely replace the context URL with our own, and make our remote context list the W3 one. But I think it's clearer and better to keep the original URL and just add stuff rather than replace)

(Something we could do that would keep the use of AS2 terms the same is to entirely replace the context URL with our own, and make our remote context list the W3 one. But I think it's clearer and better to keep the original URL and just add stuff rather than replace)
zPlus commented 3 years ago
Owner

The w3 URL is an actual prefix.

Using actor or as:actor or https://www.w3.org/ns/activitystreams#actor shouldn't really matter, every JSON-LD library should be able to parse these object by changing frames. Only programs parsing these object as JSON (instead of JSON-LD) would have compatibility problems... but should we care about this anyway?

The w3 URL [is an actual prefix](https://www.w3.org/ns/activitystreams#h-introduction). Using `actor` or `as:actor` or `https://www.w3.org/ns/activitystreams#actor` shouldn't really matter, every JSON-LD library should be able to parse these object by changing [frames](https://www.w3.org/2018/jsonld-cg-reports/json-ld-framing/). Only programs parsing these object as JSON (instead of JSON-LD) would have compatibility problems... but should we care about this anyway?
fr33domlover commented 3 years ago
Collaborator

I know it's a prefix :) What I'm saying is, it's not just a prefix. If you download the actual JSON-LD context from that URL (iirc you can do that with curl etc. by providing an Accept header so that you get the JSON-LD instead of that HTML page), you'll see what the context contains. It does contain many local terms, but it also contains stuff like the "xsd" prefix. If you use the w3 URL as a prefix and not as a remote context, you exclude the "xsd" term and anything else that doesn't live directly under that w3 URL.

So potentially it may break stuff. The w3 URL happens to be used a prefix, but, it doesn't have to. It just happens to be, but the actual use of it in AP is as a remote context. We could change the @context we use, but I suggest that at least for now, let's avoid the complication of going over the remote context to make sure nothing breaks, and simply keep using it as a remote context. Simply because it's safe and easy and most compatible with other stuff.

Should we care about programs that handle JSON-LD as plain JSON? Well, I think most AP supporting platforms so far use JSON-LD, but most!=all and especially if we want to welcome easy use and experimentation with our work, I think it's nice to continue allowing the AP stuff to work with plain JSON. We can always break it later; for now, there's no harm keeping stuff as is.

I know it's a prefix :) What I'm saying is, it's not *just* a prefix. If you download the actual JSON-LD context from that URL (iirc you can do that with curl etc. by providing an Accept header so that you get the JSON-LD instead of that HTML page), you'll see what the context contains. It does contain many local terms, but it also contains stuff like the "xsd" prefix. If you use the w3 URL as a prefix and not as a remote context, you exclude the "xsd" term and anything else that doesn't live directly under that w3 URL. So potentially it may break stuff. The w3 URL happens to be used a prefix, but, it doesn't have to. It just happens to be, but the actual use of it in AP is as a remote context. We could change the @context we use, but I suggest that at least for now, let's avoid the complication of going over the remote context to make sure nothing breaks, and simply keep using it as a remote context. Simply because it's safe and easy and most compatible with other stuff. Should we care about programs that handle JSON-LD as plain JSON? Well, I think most AP supporting platforms so far use JSON-LD, but most!=all and especially if we want to welcome easy use and experimentation with our work, I think it's nice to continue allowing the AP stuff to work with plain JSON. We can always break it later; for now, there's no harm keeping stuff as is.
fr33domlover commented 3 years ago
Collaborator
This is the remote context file: <https://github.com/rhiaro/as-ns/blob/master/activitystreams.jsonld>
fr33domlover commented 3 years ago
Collaborator

(Btw it defines an "as" prefix (pointing to itself..) so you can already use "as:Note" etc. without changing the context at all)

(Btw it defines an "as" prefix (pointing to itself..) so you can already use "as:Note" etc. without changing the context at all)
fr33domlover commented 2 years ago
Collaborator

I noticed that in the AS2 context, only non-prefixed terms have "@type": "@id". We could do that for namespace prefixed terms too, e.g. frg:Repository, but either way, we need a context document. But where do we host it? One option is w3id.org, another is peers.community. As long as it's a draft, let's use peers.community, and with a stable spec we can easily switch if we want to.

So, the @context would like this:

{
    "@context": [
        "https://www.w3.org/ns/activitystreams",
        "https://peers.community/ns/forgefed"
    ],
    "id": ...
    "type": ...
}

The ForgeFed context would define non-prefixed versions of all terms, but also define a prefix, much like AS2 defines an "as" prefix. Proposal: the prefix will be "frg".

On the Fediverse, and in Vervis, there are more vocabularies used for some objects. But those can be mentioned in the spec for the relevant object. Otherwise, I propose the context example above as the standard one for ForgeFed. It simply lists 2 remote contexts, the standard AS2 one and our ForgeFed extension.

@zPlus, what do you think? :)

I noticed that in the AS2 context, only non-prefixed terms have `"@type": "@id"`. We could do that for namespace prefixed terms too, e.g. `frg:Repository`, but either way, we need a context document. But where do we host it? One option is w3id.org, another is peers.community. As long as it's a draft, let's use peers.community, and with a stable spec we can easily switch if we want to. So, the `@context` would like this: ``` { "@context": [ "https://www.w3.org/ns/activitystreams", "https://peers.community/ns/forgefed" ], "id": ... "type": ... } ``` The ForgeFed context would define non-prefixed versions of all terms, but also define a prefix, much like AS2 defines an "as" prefix. Proposal: the prefix will be "frg". On the Fediverse, and in Vervis, there are more vocabularies used for some objects. But those can be mentioned in the spec for the relevant object. Otherwise, I propose the context example above as the standard one for ForgeFed. It simply lists 2 remote contexts, the standard AS2 one and our ForgeFed extension. @zPlus, what do you think? :)
zPlus commented 2 years ago
Owner
  1. we could host a web space at forgefed.peers.community if useful, so it can be used as namespace too
  2. I prefer the prefix "forgefed" or "forge" or "ff"
  3. the double context is a problem for me, it would be much simpler if we could condense it into one because it's simpler for developers and doesn't require using a prefix in the JSON document ("frg:Repository" vs just "Repository")
1. we could host a web space at forgefed.peers.community if useful, so it can be used as namespace too 2. I prefer the prefix "forgefed" or "forge" or "ff" 3. the double context is a problem for me, it would be much simpler if we could condense it into one because it's simpler for developers and doesn't require using a prefix in the JSON document ("frg:Repository" vs just "Repository")
fr33domlover commented 2 years ago
Collaborator

@zPlus, it doesn't require a prefix either way! As to 1 context URI, we can internally include the AS2 context and use only the ForgeFed one, but I don't think it's a good idea:

  1. People can't use a modified AS2, should they wish to
  2. If AS2 gets an update causing name shadowing, we're in trouble
  3. There are more contexts we need, and the Fediverse needs, we can't keep including every context we need, it will end up causing interop problems, because
  4. The convention is multiple URIs

There's no harm in using 2 URIs, or more when needed, it's safe and commonly done already. And plain JSON implementations don't need the context anyway.

What do you think @zPlus? Which advantage do you see for using 1 big context?

As to prefix, ok how about we use "forge" then?

@zPlus, it doesn't require a prefix either way! As to 1 context URI, we can internally include the AS2 context and use only the ForgeFed one, but I don't think it's a good idea: 1. People can't use a modified AS2, should they wish to 2. If AS2 gets an update causing name shadowing, we're in trouble 3. There are more contexts we need, and the Fediverse needs, we can't keep including every context we need, it will end up causing interop problems, because 4. The convention is multiple URIs There's no harm in using 2 URIs, or more when needed, it's safe and commonly done already. And plain JSON implementations don't need the context anyway. What do you think @zPlus? Which advantage do you see for using 1 big context? As to prefix, ok how about we use "forge" then?
zPlus commented 2 years ago
Owner

"forge" is OK for me. Anyway, the reason I'd prefer a single context is because it makes life a little bit easier for whoever has to implement the protocol. But I see your points. My pet peeve is that with multiple contexts Note becomes as:Note and Repository becomes forge:Repository. This is a problem for platforms that parse activities with JSON instead of JSON-LD. Granted, this is of course their problem because the spec is clear about using JSON-LD, but if there's a way to avoid it... :P

"forge" is OK for me. Anyway, the reason I'd prefer a single context is because it makes life a little bit easier for whoever has to implement the protocol. But I see your points. My pet peeve is that with multiple contexts `Note` becomes `as:Note` and `Repository` becomes `forge:Repository`. This is a problem for platforms that parse activities with JSON instead of JSON-LD. Granted, this is of course their problem because the spec is clear about using JSON-LD, but if there's a way to avoid it... :P
fr33domlover commented 2 years ago
Collaborator

@zPlus, let me say that again: Even with multiple contexts, you can use Repository and Note without a prefix!

The AS2 context puts terms such as Note in the "global scope". And then the ForgeFed context puts more terms, such as Repository, in the global scope. And you can just use them freely without as: or forge: prefixes!

@zPlus, let me say that again: **Even with multiple contexts**, you can use `Repository` and `Note` without a prefix! The AS2 context puts terms such as `Note` in the "global scope". And then the ForgeFed context puts more terms, such as `Repository`, in the global scope. And you can just use them freely without `as:` or `forge:` prefixes!
zPlus commented 2 years ago
Owner

OK you're right, this is the specification for reference.

The active context refers to the accumulation of local contexts that are in scope at a specific point within the document

and

If a term is redefined within a context, all previous rules associated with the previous definition are removed

basically the prefix is only required if ForgeFed terms conflict with AS terms.

OK you're right, [this is the specification](https://www.w3.org/TR/2014/REC-json-ld-20140116/#advanced-context-usage) for reference. > The active context refers to the **accumulation** of local contexts that are in scope at a specific point within the document and > If a term is **redefined** within a context, all previous rules associated with the previous definition are removed basically the prefix is only required if ForgeFed terms conflict with AS terms.
fr33domlover commented 2 years ago
Collaborator

Yes :)

So, I'm closing the issue. Decisions:

  • There will be a ForgeFed context document, the current URI to use in examples is https://peers.community/ns/forgefed, but it may change later (to use forgefed.peers.community or w3id.org or something else)
  • A typical @context will be a JSON array with 2 contexts listed, the standard AS2 one and the ForgeFed one (see example in the comments above)
  • The ForgeFed context document will define a term for use as a prefix, and the term will be named "forge" (much like the AS2 context defines the "as" prefix)
  • When other extensions or contexts are needed (such as the security vocabulary, used on the Fediverse for actor keys), it will be clearly stated in the specification
Yes :) So, I'm closing the issue. Decisions: - There will be a ForgeFed context document, the current URI to use in examples is `https://peers.community/ns/forgefed`, but it may change later (to use `forgefed.peers.community` or `w3id.org` or something else) - A typical `@context` will be a JSON array with 2 contexts listed, the standard AS2 one and the ForgeFed one (see example in the comments above) - The ForgeFed context document will define a term for use as a prefix, and the term will be named "forge" (much like the AS2 context defines the "as" prefix) - When other extensions or contexts are needed (such as the security vocabulary, used on the Fediverse for actor keys), it will be clearly stated in the specification
zPlus commented 2 years ago
Owner

Edit: we just agreed on IRC (at #peers) to use the URI "forge": "https://forgefed.peers.community/ns#" because it's less likely to change and also easier to add a document at that address in the future.

Edit: we just agreed on IRC (at #peers) to use the URI `"forge": "https://forgefed.peers.community/ns#"` because it's less likely to change and also easier to add a document at that address in the future.
Sign in to join this conversation.
Loading...
Cancel
Save
There is no content yet.