- From: Jacopo Scazzosi <jacopo@scazzosi.com>
- Date: Mon, 6 Nov 2023 16:06:05 +0100
- To: Melvin Carvalho <melvincarvalho@gmail.com>
- Cc: Stian Soiland-Reyes <soiland-reyes@manchester.ac.uk>, Jonas Smedegaard <jonas@jones.dk>, Kingsley Idehen <kidehen@openlinksw.com>, "public-webid@w3.org" <public-webid@w3.org>
Hi all,
> We could use that system to decide whether or not to close the group.
Based on the numbers I’m seeing, this feels like the most appropriate course of action. But, I myself was late in joining the conversation, perhaps others will join soon.
> Or to carry on and complete Nathan's suggestion.
I think Nathan’s approach, going back to the "superset and subset specification” thread, is promising. Quoting his latest summary:
> WebID broadly defines a <uri> which dereferences to an RDF response that asserts <uri> a webid:Agent, is a webid. (note about 303)
>
> WebID also defines an open ended list of sub specifications, where for each valid rdf response type, webid-{type} is an implementation which is constrained to require only that specific type.
>
> With that, we'd cover all bases, and webid-turtle, webid-jsonld, and many more, would automatically fall out.
>
> The specification would likely never need to be updated, be quite concise, and require only the publication of a simple vocabulary to cover webid:Agent, or some such universal term.
>
> The current webid specification, would be superseded by both WebID, and its inferred subspecification WebID-Turtle.
Orthogonally to this, we could have WebID-TLS and other various method of user authentication, meaning an implementor would be free to, say, implement WebID-TLS on top of WebID-Turtle.
I’m also strongly against supporting URNs as that would completely redefine what a WebID is and, incidentally, make something such as WebID-TLS impossible to build considering that URNs cannot be dereferenced.
Best,
Jacopo.
Received on Monday, 6 November 2023 15:06:24 UTC