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.
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:
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.
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.
https://w3id.org/fephttps://w3id.org/fep/888dhttps://w3id.org/fep/888d/SomeTypehttps://w3id.org/fep/888d.jsonld$ 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>
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.
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)?
Try the curl with Accept: application/ld+json – that should work.
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.
(Nit-pick: Technically a mapping to the Forgejo app.ini since Codeberg is based on this Gitea soft fork)
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.
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
The Codeberg Pages issue seems to still be unresolved.
I am in the meantime thinking about supporting content negotiation with the .htaccess redirect rules. FEP-0391 has definitions and RDF schema for two properties (inReplyToProof and contextProof) which are available in Turtle, RDF/XML, and JSON-LD. I think it should be possible to update the mapping to support such a use case, with mild-to-moderate effort.
Two PRs implementing support for proper term definitions as JSON-LD, RDF/XML, and/or Turtle ontologies/schemas. This should be the last thing before the FEP can hopefully be pushed to FINAL status.
A folder within the FEP’s directory should be used to provide additional documentation for the term, such as ontology or schema definitions via JSON-LD, RDF/XML, and/or Turtle.
Is this sub-folder REQUIRED when using paths?
I added context.jsonld document to FEP-ef61 folder, but it doesn’t seem to work in JSON-LD playground. The gateways property in actor example is parsed as a blank node.
Oh interesting, FEP-c390 example is working now. FEP-c390 doesn’t have a sub-folder, but it has a file with the same name as the defined term, placed alongside context.jsonld document.
no, it’s just a recommended best practice (“should”). i don’t think that property names are required to resolve, but if they do, the .htaccess file supports mapping terms to RDF serializations based on content negotiation.
i’m not sure why or when json-ld playground examples work, but that would be a separate concern.
The problem was caused by an error in context.jsonld. I fixed it and now JSON-LD playground parses documents correctly. Also, https://w3id.org/fep/ef61/gateways resolves to the text file, as expected.
Looks like FEP-888d is ready for finalization.
More or less! The last remaining concern I have is that ontology definition is still a little awkward because you don’t have a standardized way/option to package the ontology in a single file (i.e. using #property instead of /property) – the RDF-supporting .htaccess rules currently only work on a per-property basis.
The blockers to doing that:
ontology.owl or ontology.jsonld or so on. BUT…Accept: text/turtle on https://w3id.org/fep/xxxx should return the ontology. That much is straightforward. The showstopping problem is that we already use application/ld+json to point to the context file and not the ontology document. I’m not aware of how this is generally handled or resolved, what the best practices might be. Off the top of my head, this seems to be what application/ld+json; profile="http://www.w3.org/ns/json-ld#context" is intended to solve… but I am unsure of how the wider JSON-LD ecosystem handles or fails to handle that profile parameter. It feels like potentially fragile behavior to say that the requester must specifically request the context profile and not just jsonld. But I could be wrong, this might actually be the correct intended solution.@trwnh At fep issue tracker there’s a new comment about a possible bug in examples: #83 - [TRACKING] FEP-888d: Using https://w3id.org/fep as a base for FEP-specific namespaces - fediverse/fep - Codeberg.org