A social profile is not a discovery mechanism

[woutermont]

The WebID-Profile draft contains a number of recommendations which seem to privilige some (unspecified) pieces of data, lifting them out of the normal mechanisms of discovery. In this issue, I would like to discuss the reasons and problems of such an approach.

Concretely, the draft contains the concept of a Preferences File, pointed to from the Profile Document, as well Extended Profile Documents, pointed to from the Profile Document, the Preferences File, or other Extended Profile Documents. The idea is to have these documents contain "all statements with the WebID as subject," and use the proliferating structure of documents to regulate access (in quite an untenable way, as @RubenVerborgh has already pointed out). For example, consider the following paragraph from the introduction.

Keisha's Solid profile might list her name publicly, her phone number only for friends, and the configuration settings for her "notes to self" only for apps operating on her own behalf. Solid supports these options by splitting the profile into documents with separate access restrictions. So the first task of an application may be to load all of the profile documents it has access to or load them on a need to basis.

A first question that bothers me is: why are those triples so special? If I store photos in my pod, sorted into albums using metadata, these are photo albums. Whether or not I decide to add a me: photo:hasAlbum <./albums/xyz#this> triple to those albums should i.m.o. not influence the discoverability of my album from my Extended Profile. The other way around, if I use me: vcard:n <./info#name> instead of me: vcard:fn 'Wouter Termont', suddently my name is no longer part of my Extended Profile. I fail to see how this can be desired behavior.

If not the special status of these triples with the WebID as subject, then what makes some data deserve to be in the profile and other data not? The fact that they identify the referent of the WebID? But then my entire gene sequence might be a better candidate for the Profile than my name. Moreover, "configuration settings for [someones] 'notes to self'" are hardly identification.

---

The conclusion must be that the WebID-Profile proposal recommends a rather random selection of data to be present in the profile. This, in its own, leads to even more problems. How, for example, will an app know where to look for a specific piece of data? Shall it find it by crawling the possibly complex web of Extended Profile Documents? Or should it rather look for it via an indexing/registry system? What if it finds the data via both ways, but it conflicts? What if it does not find it via either way; where should it then store its initial value? What if one app stores data of type X using one mechanism, yet afterwards you'd like to use another app to process that data, but this app can only use the other mechanism?

I hope to have pointed out clearly a number of issues with the Preferences File and Extended Profile Documents proped by WebID-Profile. My initial suggestions based on them would be:

• to rethink the idea of having "profile data" that is separate from other data;
• to brainstorm with the people from SAI about how we can use interfaces which make discovery mechanisms really compatible/interchangeable;
• to try to build a social media style profile on top of a (separate) discovery specification (if that is what this specification wants to do).

[jeff-zucker]

rethink the idea of having "profile data" that is separate from other data

A noble goal, but not one of this specification. Our task is to document existing practices and make recommendations related to those existing practices. All existing apps I am aware of that seek to find out about a Social Agent use this concept of a profile that consists of a graph of statements with the WebID as subject. That is the situation we will document.

Or should it rather look for it via an indexing/registry system?

That will be nice when it is possible. We are documenting what exists today, that doesn't. [Edit: yes in the general case this is possible now and we will point to other specs about them]

I hope to have pointed out clearly a number of issues with the Preferences File and Extended Profile Documents

Again, it might be nice to live in a world where those things didn't exist, but the current world isn't that one.

How, for example, will an app know where to look for a specific piece of data?

We will be covering that in detail with multiple use cases.

What if one app stores data of type X using one mechanism, yet afterwards you'd like to use another app to process that data, but this app can only use the other mechanism?

Our document is about things that exist. What other existing mechanism are you referring to?

[jeff-zucker]

A social profile is not a discovery mechanism

Perhaps, but discovery of a social profile is. This spec will only indirectly cover most social profile predicates, leaving those descriptions for related documents for Persons and Organizations in the future. However this spec is aimed at developers and therefore needs to be a framework for the start of the discovery process. Discovering where an Agent puts their social profile information is a key part of that process and will be covered in this spec.

[woutermont]

Our task is to document existing practices and make recommendations related to those existing practices.

Please read my argumentation in #68. The document being drafted here can either be a descriptive one or a normative one, not both. The arguments I give are based on a normative reading (which I infer from the wording used), so rebuttals of the form "this is the way it is being done" are not valid (unless accompanied by a clear need for compatibility and a clear argument that this can't be achieved by my counterproposal).

A social profile is not a discovery mechanism

Perhaps, but discovery of a social profile is. [T]his spec is aimed at developers [...] Discovering where an Agent puts their social profile information is a key part of that process [...]

If this spec is aimed at developers, it would take into account interoperability, performance, number of libraries etc. (on all of which this spec scores low), not the fact that an insignificant amount of early adopters will have to update their profile a bit.

Or should it rather look for it via an indexing/registry system?

[...] [I]n the general case this is possible now and we will point to other specs about them

My point was not that an indexing system itself was a problem, but rather that when we have two or three indexing mechanisms (e.g. extended profiles, type indexes, and SAI registries), the client will not know where to discover existing data, where to write non-existing data, and definitely not how to interact with other apps using the same data.

What if one app stores data of type X using one mechanism, yet afterwards you'd like to use another app to process that data, but this app can only use the other mechanism?

Our document is about things that exist. What other existing mechanism are you referring to?

I'm talking about extended profiles, type indexes, and SAI registries; three discovery mechanisms that exist. One piece of data could be stored and retrieved via any of those mechanisms, and work perfectly with one app, but as soon as a second app comes into play, it's a free for all; no interoperability at all.