Subsets of the Superset

[melvincarvalho]

Once the superset specification has been drafted, we will also need subset specs as outlined in #17

Which ones should be selected?

Here's my votes:

+1 JSON-LD +1 Turtle

-1 RDFa -1 anything that mandates XHTML

+0 everything else

The reasoning behind this is to align with current adoption, popularity with web developers, backwards compatibility, and areas that have a chance of achieving broad adoption and growth.

Happy to hear other opinions on this.

[jacoscaz]

Pinging @kidehen, @webr3, @jonassmedegaard, @acoburn, @TallTed, @woutermont, @namedgraph, @csarven amongst others.

My vote goes for JSON-LD (opt. in data islands), RDFa, Turtle (opt. in data islands) on the format side and WebID-TLS on the feature side (these two sides are orthogonal to one another).

[webr3]

RDFa looks the odd one out JSON-LD & Turtle (+Data Islands) seems more than enough work, and caters to json typical devs and the most common sem web.

Consider, in HTML you can use RDFa, or a data island in JSON, OR Turtle, it's one too many to be clear with a reasonable default.

[jacoscaz]

Consider, in HTML you can use RDFa, or a data island in JSON, OR Turtle, it's one too many to be clear with a reasonable default.

@webr3 I like your point! If data islands were to be supported by WebID-Turtle and WebID-JSONLD there would be no need for this group to also specify WebID-RFDa. Agreed. Of course, this would leave others free to do so if needed.

[TallTed]

I am unclear on what is being asked/decided in this issue.

I cannot tell what the "superset specification" is (or is to be).

Nor can I tell what the full list of possible "subset specs" is. Listed here, I see 3 specifics (JSON-LD, Turtle, RDFa) and 2 wildcards ("anything that mandates XHTML", "everything else").

None of this seems to be outlined in #17.

Could someone try to re-write/summarize the question (issue) being discussed here, in (relatively) plain language?

[jacoscaz]

Hi @TallTed !

Here's a few links that might help to contextualize this:

1. New chair: https://lists.w3.org/Archives/Public/public-webid/2023Nov/0121.html
2. Nathan's superspec/subspec proposal: https://lists.w3.org/Archives/Public/public-webid/2023Jul/0056.html , originating in https://github.com/w3c/WebID/issues/17
3. Super-early superspec draft: https://jacoscaz.com/WebID/superspec/webid.html

Fundamentally, the idea is to produce a minimal WebID "superspec" (I think another word to describe it would be a framework spec) focusing on the underlying concepts and mechanisms of WebIDs while leaving serialization formats (Turtle, JSON-LD, ...) and specific features (TLS, OIDC, ...) up to subspecs.

The end result should, of course, be functionally compatible with the current version of the spec. The intention is not to create something functionally different but, rather, to re-organize the spec so as to overcome the current impasse and finally get to WebID 1.0.

Amongst other triggers, all this was prompted by the Solid WG intention of taking over the WebID spec, given the long wait for WebID 1.0: https://github.com/solid/solid-wg-charter/issues/39 . I don't mean this in a bad way, I actually think handing everything over to the Solid WG group is a good idea. But, there is tangible consensus around the superspec/subspec approach and it does feel worth a try.

As for how I became chair... I honestly do not know.

[jacoscaz]

As per the email thread I've opened in https://lists.w3.org/Archives/Public/public-webid/2023Nov/0144.html , part of the answer to this question depends on how we look at the relationship between different kinds of subspecs, particularly from the perspective of how implementors would have to describe their implementations of WebID.

For example, the description WebID-TLS over WebID-Turtle and WebID-JSONLD implies the following separate and explicit subspecs:

• WebID-TLS (a "feature" subspec)
• WebID-Turtle (a "format" subspec)
• WebID-JSONLD (a "format" subspec)

Although technically explicit, this approach quickly becomes somewhat awkward when we consider a more complex example such as WebID-OIDC and WebID-TLS over WebID-Turtle, WebID-JSONLD and WebID-DataIslands.

Perhaps we could adopt a more lightweight approach whereby subspecs would only focus on features (WebID-TLS, WebID-OIDC, ...) and the superspec would define how implementors could qualify their implementations in terms of which RDF formats they supported. Examples:

• WebID-TLS over Turtle and Data Islands
• WebID-OIDC over JSON-LD

I think this approach would maintain the spirit of the superspec / subspec proposal while making the spec even more approachable and future proof. Thoughts?

[melvincarvalho]

Good idea to separate formats (serializations) and features (authentication, signing, encryption, delegated login). We dont want a big NxM matrix which would be confusing. Instead two sections, one for serializations, one for features. The subset specs can standardize the way they want, based on how the system is used.

[webr3]

yes data schema (+version)

• feature specs (+versions)
• serialisations

a question is do feature additions iterate the base schema version, as many will require properties to be defined or aliased

b.c. is important, be nice if the schema was append only and was always backwards compatible

then detecting features for use is just if data has property and implementation of the to be actioned functionality is based on the feature spec version

serialisations also have versions, but that may be agnostic to this, more of a "tested with rdf-x.x" and here's an example encoding of the data using that media type, or special guidance if required (ideally this is a moot point).

On Sat, 9 Dec 2023, 17:28 Melvin Carvalho, @.***> wrote:

Good idea to separate formats (serializations) and features (authentication, signing, encryption, delegated login). We dont want a big NxM matrix which would be confusing. Instead two sections, one for serializations, one for features. The subset specs can standardize the way they want, based on how the system is used.

— Reply to this email directly, view it on GitHub https://github.com/w3c/WebID/issues/21#issuecomment-1848589071, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAB4LA6Y66E2XQ62AX2TX3DYISNVBAVCNFSM6AAAAAA7HMZPQ2VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQNBYGU4DSMBXGE . You are receiving this because you were mentioned.Message ID: @.***>

[woutermont]

Just a suggestion, because the language appears to be confusing to a number of people, and I can see why...

Can we stick to the terminology defined in the W3C Note on Variability in Specifications?

[woutermont]

Also: before diving into which data formats or features to support, let's park that and focus on the core definition(s)?

[jacoscaz]

Can we stick to the terminology defined in the W3C Note on Variability in Specifications?

@woutermont very good point and suggestion, I fully agree. In trying to consider how that note can apply to WebID I have come up with the following:

1. the WebID spec should be designed for extensibility through an open-ended list of profiles
2. each profile should focus on a specific feature (e.g.: WebID-TLS for authentication through client-side certificates)
3. the spec, and not one of its profiles, should regulate how implementors should qualify their implementations in terms of supported serialization formats

What do you think? How would you apply that note to WebID?

Also: before diving into which data formats or features to support, let's park that and focus on the core definition(s)?

I agree in principle. For the time being I've intentionally opted to prioritize "breadth-first" rather than "depth-first" until the end of today, focusing on opening new fronts rather than closing existing ones. I feel this is more appropriate in light of https://lists.w3.org/Archives/Public/public-webid/2023Nov/0160.html, which triggered a process that should end in a few hours from now.

[woutermont]

• the WebID spec should be designed for extensibility through an open-ended list of profiles
• each profile should focus on a specific feature (e.g.: WebID-TLS for authentication through client-side certificates)
• the spec, and not one of its profiles, should regulate how implementors should qualify their implementations in terms of supported serialization formats

I actually think this is precisely the way to go 👍

[jacoscaz]

Can we stick to the terminology defined in the W3C Note on Variability in Specifications?

1. the WebID spec should be designed for extensibility through an open-ended list of profiles
2. each profile should focus on a specific feature (e.g.: WebID-TLS for authentication through client-side certificates)
3. the spec, and not one of its profiles, should regulate how implementors should qualify their implementations in terms of supported serialization formats

I actually think this is precisely the way to go 👍

Excellent. Does anyone in the group object to this way forward? I think this question is particularly relevant for @kidehen, @TallTed and @jonassmedegaard.

[csarven]

Fundamentally, the idea is to produce a minimal WebID "superspec" (I think another word to describe it would be a framework spec) focusing on the underlying concepts and mechanisms of WebIDs while leaving serialization formats (Turtle, JSON-LD, ...) and specific features (TLS, OIDC, ...) up to subspecs.

The end result should, of course, be functionally compatible with the current version of the spec. The intention is not to create something functionally different but, rather, to re-organize the spec so as to overcome the current impasse and finally get to WebID 1.0.

Amongst other triggers, all this was prompted by the Solid WG intention of taking over the WebID spec, given the long wait for WebID 1.0: https://github.com/solid/solid-wg-charter/issues/39 .

If so, that premise is misleading. By definition CGs are spaces to incubate work, in a nutshell, and WGs to take work as input (from open incubation spaces) and advance the work forward on the standardisation track at W3C. There are different expectations, licensing, constraints, resources, participation, and so forth for each Group type. The "idea" of the (WebID) CG was never to release WebID 1.0 as though it is polished and immutable, and hand it over to a WG or be rubber-stamped by W3C. Such thing would go against W3C's framework, processes, and recommendations.

Furthermore, the idea to split the current specification, instead of updating where necessary is both convoluted and doesn't actually change much at the end of the day. If the notion of the WebID, as the identifying component, needs to be clarified, that can be done so through the definitions, and if not, conformance requirements, in the current WebID 1.0 ED. It does not justify a whole new specification on its own. There is a higher bar to change what has been demonstrated to work; implemented, adapted, and adopted. Any other specification or implementation that needs to use the WebID's identifying component can literally do so by referring to its specific definitions and requirements as necessary. The specification can literally outline the classes of products and expected interoperability. That's where I believe the major improvements can be put in place - without attempting to reinvent the wheel.

WebID and WebID-TLS, to take an example, are already different specifications. And, so can WebID-OIDC or whatever else that if anyone would like to make such proposal. The onus is on those to make those proposals, including commitment to implement, demonstrating use, adoption, and so forth over time, instead of exercising architecture astronomy - if no one asked for WebID-OIDC, what are we doing actually? (Aside: Solid, originally started with WebID-OIDC, but then changed to Solid-OIDC).

As for the whole idea of having WebID-Turtle and WebID-JSON-LD or WebID-{concrete-RDF-syntax} or whatever, creating "subspecs" of such based on serializations is nearly unheard of out there. Not only that, it demonstrates a misunderstanding of RDF or creates unnecessary friction. I've even spotted suggestions on the mailing list being made along the lines of "WebID-TLS over Turtle and JSON-LD" or "WebID-OIDC over JSON-LD and RDFa", which makes no sense to me whatsoever.

On a related note, perhaps one of the most interesting things here about ensuring interoperability, and in particular what classes of products are intended to interop: superspec'ing and subspec'ing does not actually solve or improve anything even on paper. When I said I'm worried about potential fragmentation being created in another thread, part of that was in reference to the proposal to creating separate specs (if one even could call it a 'spec') where each focus on a particular concrete RDF syntax. That would virtually break all hopes of legitimate interop, and thus the fragmentation, because what would actually happen is that some implementations will only use Turtle, and the other JSON-LD, and yet another something else. Those implementations, while conforming on the "superspec" - architecture astronomy - will never conform on the subspec level, which is where things will actually work (or not) for the user. Unless of course the requirement becomes infinitely more complicated for the consumer (in comparison to what we have now in the ED) in that they'll have to understand all concrete RDF syntaxes.

I don't believe I got a response to what I said in https://github.com/w3c/WebID/issues/3#issuecomment-898630571 , and the rest of the perma-thread turned me off. Some of the points were:

• Positioning of the WebID 1.0 spec - saying do "concrete RDF syntax", and nothing more, and then have "higher level specifications" (e.g., Solid Protocol, Solid-OIDC, WAC,.. that employs WebID) make the call on specific syntaxes as they need to. This is a different take on the current WebID 1.0 ED because it actually removes Turtle. It changes what constitutes interoperable, and would be a class 3 correction, if not a 4. The superspec, without the subspec, idea is partly compatible with this approach.
• Minimum requirements for what constitutes "interoperable" in the ecosystem between classes of products. It is not rocket science: if more than one serialization is required to be implemented by any product to conform, that is without a doubt more complicated than requiring a single serialization. YMMV as to what's the "best" serialization, see either the approach in point above or below to get around this.
• Require both Turtle and JSON-LD.

Again, alternative proposals have a higher bar to demonstrate exactly what conformance requirements are being introduced to achieve the same, if not, "better" level of interoperability. I've read speculations and rhetoric but not actual implementations or supporting data.

I don't mean this in a bad way, I actually think handing everything over to the Solid WG group is a good idea. But, there is tangible consensus around the superspec/subspec approach and it does feel worth a try.

That would give the appearance that something is changing or being better. There is no data supporting why or how the alternative approach is actually preferable to the current work. FWIW, the Solid CG backed the approach in WebID 1.0 ED towards the WG, not alternatives.

As I've mentioned elsewhere, the current WebID 1.0 ED, despite it being stale in parts and can benefit from some editorial, if not some authoring level updates, is about as "successful" as any CG output can get. It has incubated the work in its fullest sense of the word; on spec level, implementation, dependency from other specifications, research, and so forth.

My proposal to advance the work through a WG, may it be Solid, was simply to check a number of boxes that's of mutual interest to various stakeholders. The possibility through a Solid WG just happened to be coincidental or perhaps most meaningful or feasible at this time. And so I suggested to take that as some advantage FWIW. I tried to make sure that my proposal (at least towards the Solid WG charter) was clear in that the WebID specification should not "introduce breaking changes" and should "stand on its own", making sure for instance that it works as it is originally designed and not be changed into something that would be limited to Solid. And, on a relate note, if/when the Solid WG successfully delivers WebID, any future work on WebID can be continue to be carried out at its home in the WebID CG, instead of the Solid CG for example. Those are just my general recommendations, where some are acknowledged and adopted, but certainly do not represent all Groups or even what Groups may actually do years from now. Too many variables to worth or risk doubling down on anything.

---

As I've said elsewhere, I can serve as editor on WebID 1.0 ED... let me know if an official ceremony needs to take place...

[webr3]

Any other specification or implementation that needs to use the WebID's identifying component

See #17 the entire point is that WebID as it stands does not specify anything other than dereference to a turtle document with a single meaningless triple.

The goal of a super/sub approach, was to deal with this issue, and specifically handle #33 - leaving the rest of the noise for sub specs

[csarven]

As mentioned, if clarifying definitions and requirements is what's needed as part of list of product classes that can be interoperable, that can be done so in the current WebID 1.0 ED with minimal work.

If something is unclear or underspecified, it is useful to look at what's originally intended. As I see it, the WebID 1.0 ED in its totality can be categorised to cover: identification, foundation/abstract, protocol, content/data. The amount of requirements that's needed for products to be interoperable is neither too many or complex, so it is fine to keep them together. Anything that needs to extend any notion or requirement, can still do so without having to necessarily take on everything. It is simpler to introduce/clarify information - within the current scope of the specification - instead of taking a far more complicated path with several specs.

[kidehen]

See #17 the entire point is that WebID as it stands does not specify anything other than dereference to a turtle document with a single meaningless triple.

Are you speaking about a WebID or the WebID Specification? Either way, I don't accept your characterization.

BTW -- implementations of the WebID spec already exist, and they are based on the notion of a WebID that names an Agent unambiguously.

The main issue with the existing spec, which has been discussed in depth over the years, boils down to:

1. Turtle specificity, for WebID-Profile docs
2. Conflation with a specific authentication protocol

[webr3]

Are you speaking about a WebID or the WebID Specification? Either way, I don't accept your characterization

The WebID Specification.

If you disagree, please prove your point using the specification text to factually find the flaw on #17 - perhaps I missed a MUST when reviewing.

[melvincarvalho]

It's important to clarify that there is a consensus to divide WebID into two specifications: a superset and a subset. The Chair has confirmed this long-established agreement.

The superset will be highly minimal, akin to an "abstract class", defining the fundamental concept of a WebID as a URI that unambiguously identifies an Agent. The specifics of what constitutes an Agent and the criteria for this will be clearly outlined.

The current Editor's Draft, specific to Turtle, will remain as it has been for the past decade. However, it's tailored to Turtle. Other specifications can be developed to cater to different serialization profiles, accommodating diverse needs and preferences.

The Solid Working Group is welcome to adopt the Turtle WebID spec and enhance it as needed to ensure compliance.

Meanwhile, the WebID Community Group and related projects can freely progress, fostering innovation in the WebID domain with URIs that unambiguously denote an Agent, thereby facilitating out-of-the-box interoperability.

Given the substantial nature of this work, @jacoscaz has generously offered assistance to bring this to completion. It seems prudent to concentrate on this task before embarking on additional work iterms. Once finalized, the superset specification is expected to be sufficiently generic and stable, requiring little to no changes for years to come.

[kidehen]

The current Editor's Draft, specific to Turtle, will remain as it has been for the past decade. However, it's tailored to Turtle. Other specifications can be developed to cater to different serialization profiles, accommodating diverse needs and preferences.

The current spec can be decoupled from Turtle, via a PR.

[kidehen]

The Solid Working Group is welcome to adopt the Turtle WebID spec and enhance it as needed to ensure compliance.

I have no sense of any group seeking to adopt a Turtle-specific WebID spec. Where is this presumption coming from?

[kidehen]

Given the substantial nature of this work, @jacoscaz has generously offered assistance to bring this to completion. It seems prudent to concentrate on this task before embarking on additional work iterms. Once finalized, the superset specification is expected to be sufficiently generic and stable, requiring little to no changes for years to come.

That isn't how I understand the work being done here. The highest priority was fixing the current spec by decoupling it from Turtle, and a specific Authentication Protocol (i.e., WebID-TLS).

There is no such thing as a useful superset of the current WebID spec that won't lead to even more confusion.

All we need is a spec with the following tweaks:

1. Decoupling from Turtle
2. Decoupling from WebID-TLS, wherever that occurs (overtly or covertly)
3. Accepting properties outside FOAF for Agent and Profile Document association

Regarding point 3, here are some examples in the wild that already exist i.e., reiterating the utility of Schema.org terms.

1. https://www2.deloitte.com/us/en/profiles/beena-ammanath.html
2. https://www2.deloitte.com/us/en/profiles/nitin-mittal.html

Note: Those profile docs aren't perfect, but they indicate what's happening on the back of Schema.org terms with regards to WebIDs and associated Profile Documents.

This train has long left the station, so it would be wise to get on board by leveraging the "Wisdom of Solomon" principle that I've mentioned repeatedly.

[kidehen]

If you disagree, please prove your point using the specification text to factually find the flaw on #17 - perhaps I missed a MUST when reviewing.

That isn't how the point is proven, since I don't agree with your characterization neither here nor in issue 17.

You assert:

I can't see any specification, would be my overriding point here, all that the spec actually specifies in any implementable way, is that an HTTP URI is a WebID Profile if it dereferences to literally any text/turtle response.

My position: You are simply highlighting what needs to be fixed i.e., making the WebID Specification about the user of an HTTP URI for naming Entities unambiguously. The WebID-Profile document to which a WebID resolves is a different matter.

What's the conformance test? Naming an entity unambiguously using an HTTP URI.

Examples that pass that basic test:

1. https://www2.deloitte.com/us/en/profiles/nitin-mittal.html/#person
2. https://www2.deloitte.com/us/en/profiles/beena-ammanath.html/#person

The issue of profile document content-type only arises when implementing an Authentication Protocol, which is a totally different spec.

[webr3]

My position: You are simply highlighting what needs to be fixed i.e., making the WebID Specification about the user of an HTTP URI for naming Entities unambiguously. The WebID-Profile document to which a WebID resolves is a different matter.

What's the conformance test? Naming an entity unambiguously using an HTTP URI.

Examples that pass that basic test:

1. https://www2.deloitte.com/us/en/profiles/nitin-mittal.html#person
2. https://www2.deloitte.com/us/en/profiles/beena-ammanath.html/#person

Every HTTP URI passes that test. So what distinguishes one as a WebID, or better as naming an tbd:Agent.

[melvincarvalho]

The Solid Working Group is welcome to adopt the Turtle WebID spec and enhance it as needed to ensure compliance.

I have no sense of any group seeking to adopt a Turtle-specific WebID spec. Where is this presumption coming from?

https://lists.w3.org/Archives/Public/public-webid/2023Jul/0065.html

[kidehen]

Every HTTP URI passes that test. So what distinguishes one as a WebID, or better as naming an tbd:Agent.

The fact that it is used to denote an agent (person or organization) in a recognizable way, as per my examples. This includes human eyeballs and/or software applications i.e., not just software application which introduce content processing -- naturally.

The moment content-processing enters the mix, we enter the Profile Document realm en route to Authentication Protocol implementation -- since said protocol is all about Identity Authenticity.

Above all else, the grounding principles I espouse repeatedly regarding this matter boil down to loose-coupling of the following:

1. Identity -- an identifier offers that e.g., a WebID (which is about using an HTTP URI in this regard)
2. Identification -- a Profile Doc offers that
3. Authentication -- an authentication protocol offers that
4. Authorization -- attribute-based access controls (via ontology and processors) offer that
5. Storage -- various protocols handle that

[webr3]

The fact that it is used to denote an agent (person or organization) in a recognizable way, as per my examples. This includes human eyeballs and/or software applications

Please provide a snippet of code to implement this, if you can provide any code which given either of

https://www2.deloitte.com/us/en/profiles/nitin-mittal.html#person https://www2.deloitte.com/us/en/profiles/beena-ammanath.html/#person

can return that the URI is a WebID or has a type of tbd:Agent then we're done here, can just translate that code to a spec and be done with it.

I presume I'm missing something here and your not suggesting that if uri contains the string person then it's a webid.

[kidehen]

I presume I'm missing something here and your not suggesting that if uri contains the string person then it's a webid.

I am not saying "person" has any bearing on the example HTTP URIs I presented. I am simply saying: Here are examples of HTTP URIs used to unambiguously name agents.

An HTTP URI can be constructed from an HTTP URL by simply tacking on a "#" indexical. That's what I am referring to, specifically.

The WebID spec is supposed to be about how you construct a name from a specific kind of identifier.

[webr3]

The WebID spec is supposed to be about how you construct a name from a specific kind of identifier

This is where we differ, glad you said the above.

From my perspective the WebID spec is supposed to allow an implementer to be able to write a simple line of code like: if(X a Agent) then.

[jonassmedegaard]

I agree with @webr3 here: Scope of WebID spec is to specify what a web agent identifier is, and should specify that without expanding into stuff that is potentially ambiguous.

There are potentially multiple ways to resolve a name of an agent from an identifier of same agent, so such specification does not belong in the WebID spec. Possibly there could be multiple "wns" (WebID Name Resolving) specs, but personally I see no need for that: All the authentication specs proposed so far involve semantic graph extraction, which allows reasoning for various preferences in naming - e.g. "give me the SVG representation of the agent, or a PNG, or a textual representation - and pick the danish variant, or the norwegian, or the british english, or the irish, or if only an american english variant exists then don't resolve to that but instead show the raw IRI".

[webr3]

Scope of WebID spec is to specify what a web agent identifier is, and should specify that without expanding into stuff that is potentially ambiguous

Honestly, a vocab with class :Agent and a profile property that had the appropriate domain of Agent (and potentially where it's a sub property of schema/foaf properties in use) would cover the bases for where authors want to explicitly state a uri names an Agent or have it inferred via profile.

Just doing that, and having it in a spec which MUSTs the use of them via HTTP URIs provides a great base, and would be a major accomplishment. I would encourage all to focus on this foundation first, then later everything else if they so please.

[kidehen]

I agree with @webr3 here: Scope of WebID spec is to specify what a web agent identifier is, and should specify that without expanding into stuff that is potentially ambiguous.

That can be done in prose. Machine-computability of what's expressed in prose is something for a different spec i.e., a profile document or authentication protocol spec.

curl -I https://www2.deloitte.com/us/en/profiles/beena-ammanath.html#this
HTTP/1.1 200 OK
x-dispatcher: aemcloudservice
x-vhost: aemcloudservice
Last-Modified: Wed, 03 Jan 2024 17:31:35 GMT

Tells us that https://www2.deloitte.com/us/en/profiles/beena-ammanath.html is an unambiguous content address. Thus, it also implies that https://www2.deloitte.com/us/en/profiles/beena-ammanath.html#this is an unambiguous name derived from said address.

A WebID is simply an application of the above, but applied to naming agents (i.e., people, bots, or organizations) rather than anything.

Another possible route out of the current quagmire:

Change the "WebID Identity and Discovery Spec" title to "WebID Profile Document Spec" comprising Turtle and JSON-LD sub-specifications. As part of this approach, a WebID (part of the spec) would be described as an HTTP URI for unambiguous entity naming that resolves to documents comprising specified content types and entity relationship types -- described in the relevant sub-specifications.

What's outlined above is closer to what I believe @webr3 seeks.

[kidehen]

From my perspective the WebID spec is supposed to allow an implementer to be able to write a simple line of code like: if(X a Agent) then.

Yes, this is indeed where we differ. From my vantage point, a specification titled "WebID Specification" wouldn't be about what you describe. A specification titled "WebID Profile Document Specification" is a much closer match.

Right now, we are stuck with "WebID Identity and Discovery Specification" which, as I've mentioned earlier, is a too-clever attempt at conflating critical items that should be loosely-coupled. The checkered history of this spec is ample proof of my point.

[webr3]

What's outlined above is closer to what I believe @webr3 seeks.

Sadly, what I seek is not an HTTP URI as a Name for anything spec.

Rather I'm looking for an HTTP URI as a Name for an Agent spec, a WebID.

A spec that defines using http names for a broad group of things which are Agents, and which provides a way to determine that the named thing is an agent. Being Syntax agnostic is fine. Without the is a Agent bit, it's not a WebID as far as I'm concerned, it's just a deferenceable http name. Additionally, without it, literally every http name is a WebID, if you add an rdf constraint then every Resource is.

Specifying nothing, is imo a total waste of time.

[melvincarvalho]

Without the is a Agent bit, it's not a WebID

Agree on this part. I think the path forward is to first find a natural language definition, and then take it from there.

[melvincarvalho]

From my vantage point, a specification titled "WebID Specification" wouldn't be about what you describe. A specification titled "WebID Profile Document Specification" is a much closer match.

Open to renaming the specs, which will have to be done anyway. Perhaps we could separate that out into two distinct, but related issues, to avoid talking across each other, or overloading the chair with information in a short burst.

[kidehen]

Rather I'm looking for an HTTP URI as a Name for an Agent spec, a WebID.

As I've tried to explain, using the DBpedia example, this quest always ends up in the same place. There's a boatload of history regarding this matter that dates back to the dreaded HttpRange14 debates, and others that crept into Linked Data Principles. The core matter is the same: attempting to spec an HTTP URI as an unambiguous name for anything (agent or whatever) ends up in the same place.

Antidote? Specify the nature of the document to which an HTTP URI resolves, doing so in line with its usage purpose. That way you end up with a usage-specific definition of both an HTTP URI, the Content-Type of the document to which it resolves, and the Entity Relationship Type Semantics represented in the content.

[melvincarvalho]

Antidote? Specify the nature of the document to which an HTTP URI resolves, doing so in line with its usage purpose. That way you end up with a usage-specific definition of both an HTTP URI, the Content-Type of the document to which it resolves, and the Entity Relationship Type Semantics represented in the content.

On this, it seems a radical departure from the decade long understanding that a WebID is a URI that denotes an Agent. Perhaps you can come up with an alternative definition and propose it to the group and see if it catches on.

In any case, this thread was opened as a straw poll, and I believe it has achieved its purpose and created a few more items which can be followed elsewhere. I think we have a rough feel for the shape of extension profiles in turtle and json-ld, with more allowed, which can be ironed out in future.

[melvincarvalho]

Closing this issue as it having achieved it's purpose of straw polling and garnering opinion. Can be reopened if desired.

[jonassmedegaard]

[separately specifying identifier, profile and authentication which together specifies a valid authentic agent] seems a radical departure from the decade long understanding that a WebID is a URI that denotes an Agent.

I fail to see how it is a radical depature to separately specifying identifier and profile which together specifies a valid agent, given that those have till now only been explored as a single specification.

If you meant something else by "it" (which I replaced in my quote above), then it would be helpful if you elaborate, and I apologise for misinterpreting you.