FEP-888d: Using w3id.org/fep as a namespace for extension terms and for FEP documents

Standards Fediverse Enhancement Proposals
, , ,
21

Yes, let’s proceed to W3ID registration

Also, there is one reference that needs an update, FEP-1570: The FEP Ontology Process. The correct name of this proposal is FEP-2e40: The FEP Vocabulary Extension Process, and I recently updated the title of SocialHub discussion topic to reflect that.

22
1 Like
23

These two PRs were merged, but in testing the live deployed w3id prefix, i found that i had copy-pasted the wrong htaccess from an outdated copy. hence, the following two PRs:

24

If we are going to switch to sequential FEP IDs as discussed in the following issue, I think it would be desirable to complete the transition before stabilizing any IRIs under the new namespace.

1 Like
25

That’s fair, but really that’s a separate and larger concern.

In other news: the W3ID prefix is live already, and seems to work for all the test cases I can throw at it. If anyone can come up with test cases which fail, I’ll try to fix the mapping to handle those cases. Similarly, if anyone has any redirects that they would like to see handled but aren’t currently handled, let me know and I’ll try to accommodate those as well.

$ curl https://w3id.org/fep/888d -H 'Accept: application/ld+json'
<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<html><head>
<title>302 Found</title>
</head><body>
<h1>Found</h1>
<p>The document has moved <a href="https://codeberg.org/fediverse/fep/raw/branch/main/fep/888d/context.jsonld">here</a>.</p>
<hr>
<address>Apache/2.4.29 (Ubuntu) Server at w3id.org Port 443</address>
</body></html>

$ curl https://w3id.org/fep/888d/SomeType -H 'Accept: application/ld+json'
<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<html><head>
<title>302 Found</title>
</head><body>
<h1>Found</h1>
<p>The document has moved <a href="https://codeberg.org/fediverse/fep/raw/branch/main/fep/888d/context.jsonld">here</a>.</p>
<hr>
<address>Apache/2.4.29 (Ubuntu) Server at w3id.org Port 443</address>
</body></html>
26

The example from FEP-c390 doesn’t work in JSON-LD playground: (link).

Firefox reports the following error:

Cross-Origin Request Blocked: The Same Origin Policy disallows reading the remote resource at https://codeberg.org/fediverse/fep/raw/branch/main/fep/c390/context.jsonld. (Reason: CORS header ‘Access-Control-Allow-Origin’ missing). Status code: 200.

27

Is the https://w3id.org/fep/c390 @context URL causing the issue?

If so, when I run:

curl -v https://w3id.org/fep/c390

I see:

< HTTP/1.1 302 Found
< Date: Thu, 08 Feb 2024 02:10:13 GMT
< Server: Apache/2.4.29 (Ubuntu)
< Access-Control-Allow-Origin: *
< Location: https://codeberg.org/fediverse/fep/src/branch/main/fep/c390/fep-c390.md
< Content-Length: 330
< Content-Type: text/html; charset=iso-8859-1

Following that redirect is going to retrieve a Markdown file rather than a JSON-LD context. My browser is reporting:

jsonld.InvalidUrl: Dereferencing a URL did not result in a valid JSON-LD object. Possible causes are an inaccessible URL perhaps due to a same-origin policy (ensure the server uses CORS if you are using client-side JavaScript), too many redirects, a non-JSON response, or more than one HTTP Link Header was provided for a remote context.

Could the cause be “a non-JSON response” rather than CORS (given there does seem to be a CORS header in the response)?

28

Try the curl with Accept: application/ld+json – that should work.

1 Like
29

This appears to be a Codeberg issue… The response from raw.codeberg.org is giving Content-Type: text/plain; charset=utf8 instead of the correct application/ld+json. Examining a context document hosted on GitHub seems to work, though:

$ curl -v https://w3c-ccg.github.io/security-vocab/contexts/security-v1.jsonld
...

> GET /security-vocab/contexts/security-v1.jsonld HTTP/2
> Host: w3c-ccg.github.io
> User-Agent: curl/8.5.0
> Accept: */*
> 
< HTTP/2 200 
< server: GitHub.com
< content-type: application/ld+json
< permissions-policy: interest-cohort=()
< x-origin-cache: HIT
< last-modified: Fri, 15 Jul 2022 12:57:18 GMT
< access-control-allow-origin: *
< strict-transport-security: max-age=31556952
< etag: "62d1642e-80b"
< expires: Thu, 08 Feb 2024 04:20:55 GMT
< cache-control: max-age=600
< x-proxy-cache: MISS
< x-github-request-id: BE8E:5AE6:2A3AB5:3876F7:65C4544E
< accept-ranges: bytes
< date: Thu, 08 Feb 2024 06:26:18 GMT
< via: 1.1 varnish
< age: 0
< x-served-by: cache-cmh1290078-CMH
< x-cache: HIT
< x-cache-hits: 1
< x-timer: S1707373579.748263,VS0,VE32
< vary: Accept-Encoding
< x-fastly-request-id: b936c8eafe000d03ceb696027437309b4228b3f8
< content-length: 2059

Note that GitHub returned a content-type: application/ld+json header, as well as an access-control-allow-origin: * header.

Unfortunately, I’m not sure what the appropriate resolution here might be. The most straightforward thing to do is to have Codeberg add a MIME type for .jsonld to be mapped to application/ld+json at their server level. It appears they can set a mapping in their Gitea app.ini config file by using [repository.mimetype_mapping]:

[repository.mimetype_mapping]
.jsonld=application/ld+json

They probably need to solve the CORS issue on their end too.

2 Likes
30

(Nit-pick: Technically a mapping to the Forgejo app.ini since Codeberg is based on this Gitea soft fork)

31

After more experimentation: Using raw.codeberg.page seems to at least solve the CORS issue by adding the necessary correct header access-control-allow-origin: * to the response. But the Content-Type is still text/plain. I’ve filed #1482 - Content-Type incorrectly served as text/plain instead of application/ld+json for JSON-LD / .jsonld files - Codeberg/Community - Codeberg.org to track this issue with Codeberg’s platform.

No guarantees yet, but it seems that I will probably have to change to https://raw.codeberg.page/fediverse/fep/fep/$1/context.jsonld to solve at least the CORS issue.

2 Likes
32

Per issue 1482 the resolution seems to be to fix this for Codeberg Pages specifically (raw.codeberg.page and others) but not for /raw/ links on codeberg.org itself. A new issue has been filed against Codeberg/pages-server for tracking this: #289 - Content-Type incorrectly served as text/plain instead of application/ld+json for JSON-LD / .jsonld files - Codeberg/pages-server - Codeberg.org

1 Like