Re: Should the specs be forked and maintained elsewhere?

On Fri, 24 Mar 2023 at 01:23, Benjamin Goering <ben@bengo.co> wrote:

> from 2018 https://github.com/w3c/ac
> <https://github.com/w3c/activitystreams/issues/479>
>
>>
>> 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:
>> * activitystreams2.com -
>> https://github.com/gobengo/activitystreams2-extensions
>> * activitypub.com - https://github.com/gobengo/activitypub-extensions
>>
>
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 https://github.com/swicg with three repositories two empty and
with virtually nothing in the third but a reference to
https://www.w3.org/community/swicg/ 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: www.w3.org
    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: www.example.org <http://www.w3.org/>
    Accept: application/json

Returning :-
    {
        "context": "https://www.w3.org/ns/activitystreams",
        "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.

Regards,

Aaron