How to discover the WebID of a user?

[phochste]

In a scholarly use case, I want to create a network containing not only Solid pods but many types of nodes (for service providers, university homepages, publisher homepages, etc). On these nodes, actors use web profiles to provide information about themselves, or about their service capabilities.

In an existing network and existing data, actors can have many ids. These ids should be kept. I would like to add information to these networks that explicitly directs to a webid profile. How should I do this?

E.g. I would like to state something like

 <article> dc:creator <orcid:01231-31023> .
 <orcid:01231-31023> ???? <http://researcher.pod/#me>

Or when visiting the homepage of a researcher I would like to suggest adding a Link header (or meta tag)

????: <http://researcher.pod/#me>

I don't find a property or standardized link relation for webids. It is possible to discover LDN inboxes of a researcher in a standard way, but how to find the webid if there are many ids to choose from? Some suggested using the 'me' link relation, but that one is not in the IANA list of registered link relations.

I hope this is the correct repository for my question. I have been asking around and got no clear answer. I hope this team can lead me in the right direction.

[csarven]

I wrote about this over the years. See if the information in #58 (comment) is of help. If that issue covers this issue, we can mark this as duplicate. There are some proposed properties to relate, e.g., the ORCID (WebID) and the Solid WebID. owl:sameAs, contact:preferredURI, solid:webid, as:alsoKnownAs could be some of those possibilities depending on the nature of the relation that we want to express. (I wonder why something like foaf:accountOf wasn't defined as owl:inverseOf foaf:account because that'd be handy now :)

I don't think discovery of the WebID should require a potential exposure of the creator or maker as a Link relation. Although there is the existing author link relation type which may give you some mileage.

[hvdsomp]

I don’t see solid:webid in https://www.w3.org/ns/solid/terms# and I don’t think discovery of WebID should be tied to Solid. Doesn’t discovery of a WebID deserve a dedicated link relation given how important and unique it is? Rels like owl:sameAs and as:alsoKnownAs can be used to interlink a whole set of URIs for a person, but how does one know which one in that set is the WebID? An author rel definitely doesn’t do it because the rel must be usable to point from a URI that identifies a person but is not created/owned/authored by the person (eg an ORCID) to the person’s WebID. Using contact:preferredURI means overloading the meaning of that rel to denote WebID; the same problem would occur when using cite-as.

[csarven]

It be easier to come up with a property once we know or agree on the subject (or context).

---

Right that solid:webid doesn't exist. I threw that and other properties (ex:webid) around to move the discussion forward.

A link relation or an RDF property for the webid URI depends on the context, which is why in some ways it seems like there are existing properties that can help with different cases.

If an identifier is (considered to be) a WebID, then so would the object of its sameAs relation. However many there may be linked. Now, whether those resources and representations actually conform to the WebID identity spec is a separate matter.

There is also the matter of a generic WebID conforming to the identity spec but not necessarily be useful beyond for the purpose of reading the profile, i.e., it may not be useful towards authn/z.

Which is to say that if we need to state that the WebID we are referring to can be used in Solid for authn/z, we'd need solid:webid (or other ways of hinting that it can work in Solid). If we just need to say that an agent has a webid / also known with this other webid / or can be used interchangeably with this other webid, we end up with other different properties.

Is the use case specifically about linking from a ORCID URI to a WebID (any, not necessarily a WebID that conforms to Solid's stuff), I did this on my ORCID foaf:Agent description because it seemed to be the closest thing that can be used (at the time):

<https://orcid.org/0000-0002-0880-9125>
  owl:sameAs <https://csarven.ca/#i> .

Yes, preferredURI does overload a bit but it is not completely unreasonable either when used with a subject that happens to be a foaf:Agent. My intention with that property was along the lines of preferredWebId.

There is also the vcard:WebId Class being used/experimented in SolidOS, but I couldn't get an exact definition for that in the community. Perhaps Tim or someone else can fill in.

So, when the issue asks about the discovering the WebID of "a user", are we talking about an online account (as the subject) or are we talking about the operator? For the former, something like foaf:accountOf would've made sens. But then again, in the ORCID case, the URI is about a foaf:Person, not an foaf:OnlineAccount.

[hvdsomp]

Thanks @csarven . So, let me try and be more precise:

Rels like owl:sameAs and as:alsoKnownAs can be used to interlink a whole set of URIs for a person, but how does one know at which URI from that set the person’s profile document can be found?

Does an agent need to follow its nose to each URI in that set, all interlinked with e.g. owl:sameAs, or is there a particular relation type that can be used to point to the one and only URI from that set where the profile document can be found?

[phochste]

Yes, like in the case of Solid there could be particular reasons to introduce a 'solid:webid'. In scholarly networks there could be particular reasons to introduce a 'scholarly:webid' to point to a profile document with some scholarly properties (e.g. listing services, inboxes, outboxes, friends). In museums a 'museum:webid' for museum properties. Institutions wouldn't probably use one profile document for their more 'scholarly' tasks and another profile for their more 'museum' tasks. These profile documents will have some sort of comparable shapes but differ in details. E.g. not all profile documents will contain details to be used in Solid authentication.

We believe Webid profiles and shapes are something important to be promoted in networks. Machines should have a way to discover them without needing to guess properties or process many types of resources (probably not even RDF resources) until it matches a particular shape. In the same way an 'ldn:inbox' property exists that can be used to guess the interactions with the object of that property, we are searching for a 'webid' property..or web profile property.

[csarven]

Rels like owl:sameAs and as:alsoKnownAs can be used to interlink a whole set of URIs for a person, but how does one know at which URI from that set the person’s profile document can be found?

All or any.

Does an agent need to follow its nose to each URI in that set, all interlinked with e.g. owl:sameAs, or is there a particular relation type that can be used to point to the one and only URI from that set where the profile document can be found?

It depends! Those are equally important separate cases. Different properties may be needed for the circumstances in which they are used. It also very much depends on whether the software agent is intended to conform to a particular specification, like the Solid Protocol and/or other something else. Allow me to expand on this:

I wrote down a bunch of circumstances under which profiles are used or shared in #52 (comment) . So, for example, if software agent is interested in:

• Information for the purpose of verification, authentication, authorization purposes.
• Self-controlled and third-party-controlled identities.

then it would make sense to use a particular property (ex:webid), and have data model specification (like perhaps Solid WebID Profile) state the cardinality for that property, e.g., max 1. Bearing in mind that the underlying RDF would technically allow multiple relations with the same property. So, from the software agent's perspective, they need to follow only one of those properties.

Other examples where software agent is interested in:

• Communication and use of multiple profiles for different purposes.
• Connectivity of multiple profiles and cross-context recognition.
• Anonymous and pseudonymous profiles.
• Compilation of preferences, choices, activities and interactions of an agent.
• Social graph for different kinds of relationships between agents.
• Factors specific to physical, physiological, genetic, mental, economic, cultural, social, or behavioural identity.

can reasonably follow zero, one, or many of those properties (like owl:sameAs, as:alsoKnownAs, rdfs:seeAlso etc.) at their discretion.

Which is why I think it comes down to what's intended by a software agent. Is it general exploration or is it after something particular?

I think there are two general categories for (Solid) profile discovery:

• Incoming: Reference to a WebID from any kind of thing or document. This is highly context dependent and so virtually any property.
• Extended: Extension of a WebID description (for any purpose). This also depends on the purpose but the context is specific or known, i.e., additional information about the Agent.

So, something like owl:sameAs can be used in either case. My ORCID URI links to my csarven.ca WebID. My csarven.ca WebID may link out to my solidcommunity.net WebID. Ditto rdfs:seeAlso.

Something like dcterms:creator is meaningful under the first category.

Something like solid:webid would be meaningful for the first category. So, a software agent that understands that property and what information may be found by following its target can go for it.

Stuff like foaf:knows, pim:preferencesFile are used in the second category.

---

In the same way an 'ldn:inbox' property exists that can be used to guess the interactions with the object of that property, we are searching for a 'webid' property..or web profile property.

I'm not sure if those notions can work the same way but let's see.

If the former is like "document/thing has an inbox" what are we trying to say for the second:

"X has a profile"?

What is X?

There are countless properties that can be used for X to discover the WebID. Here I see properties like dcterms:creator to be potentially referring to a WebID. As mentioned earlier, whether what it points to conforms to the WebID identity spec is a separate matter.

---

I've created w3c/WebID#16 since that may be a more appropriate or additional place to continue the discussion, especially if what's sought here may not be strictly about Solid WebID Profiles.