Re: Should the specs be forked and maintained elsewhere?

pá 24. 3. 2023 v 16:59 odesílatel Aaron Gray <> napsal:

> On Fri, 24 Mar 2023 at 01:23, Benjamin Goering <> wrote:
>> from 2018
>> <>
>>> I own the following domains and would like to offer them up as a place
>>> to define both work-in-progress extensions as well as well-defined and
>>> stable community extensions. I will liberally accept group-namespaced
>>> work-in-progress extension definitions in their respective git repos:
>>> * -
>>> * -
> It would be good to have websites for our endeavours paralleling a github
> organization and repos for the websites and standards and code / library
> repos. Ideally these would be .org's rather than .com's though.
> There is a with three repositories two empty and
> with virtually nothing in the third but a reference to
> and no real activity since 2021 when
> the empty repos were created its owned by Aaron Parecki and Dmitri
> Zagidulin
> I propose that we collect and produce libraries in all the major languages
> for JSON-LD, ActivityPub, ActivityStreams 2, and extensions, and also for
> RDF, and OWL.
> And maybe we have a URI/IRI caching server that can redirect non normative
> URI's to JSON-LD or RDF or OWL descriptor code.
>>> I'd also support delegating any 'work-in-progress/{groupName}' directory
>>> to a git submodule, so innovation can happen in a separate repo unhindered
>>> by whoever happens to be in charge of the parent repo (whether w3c or me).
>>> I'd be happy for these repos to not be under my username. Really what
>>> I'm proposing is that brand new just-idea,
>>> potentially-shifting-under-your-feet, extensions be under
>>> `/{groupName}/{extensionName}` before taking up top-level names.
>>> Additionally, I would help work on a program to build this repo of
>>> extensions into a useful website for the community to consume them. e.g.
>>> for each extension URL:
>>> * When requested with `Accept: text/html` (e.g. by a web browser),
>>> respond with good human-readable documentation
>>> * When requested with `Accept: application/ld+json`, respond with
>>> JSON-LD describing the vocabulary in terms of rdfs/owl classes, properties,
>>> etc.
> This is an excellent idea
> I know URI's are URI's. But it would be lovely if on using the HTTP Accept
> header on a GET we could get the turtle or RDF OWL Activity Streams spec,
> rather than having to use a different path, as above.
>     GET /ns/activitystreams HTTP/1.1
>     Host:
>     Accept: text/turtle
> The main issues with this whole affair though is most people and
> implementations are working on hard hand coded code that only work with
> fixed meta data instances i.e. subsets, supersets, or intersecting protocol
> sets. And not meta descriptive agent instances.
> Being able to query a server using WebFinger and
> /.well-known/activitystreams.json for a turtle RDF or OWL spec, to the
> very minimum just the ActivityStreams 2 Standard URL :-
>     GET /.well-known/activitystreams.json HTTP/1.1
>     Host: <>
>     Accept: application/json
> Returning :-
>     {
>         "context": "",
>         "version": "2.0",
>         "normative": "true"
>     }
> But this should only be offered up by the server or agent *if and only if* it
> supports the whole normative standard, otherwise a subset, superset, or
> intersecting set, OWL turtle spec should be offered up.
> This is then just a matter of serving up a static file to be compliant for
> the more versatile to be able to communicate with them.
> This is similar to a capabilities model
> The problem is people and implementations not adhering directly to the
> full standard, I know you are allowed to implement the standard willy nilly
> in part and add fields too.
> This would normalize standards compliance as far as I see possible at this
> stage.

We used "content negotiation" in Solid, and unfortunately, it has been a
source of bugs for me. In my opinion, it was a non optimal design decision
that added a lot of complexity.

> Regards,
> Aaron

Received on Friday, 24 March 2023 16:18:09 UTC