Skip to content

Latest commit

 

History

History
160 lines (118 loc) · 15.6 KB

2022-11-16.md

File metadata and controls

160 lines (118 loc) · 15.6 KB
Raw

W3C Solid Community Group: Weekly

Present

Announcements

Meeting Recordings and Transcripts

  • No audio or video recording, or automated transcripts without consent. Meetings are transcribed and made public. If consent is withheld by anyone, recording/retention must not occur.
  • Join queue to talk.

Participation and Code of Conduct

Scribes

  • Daniel Bakas
  • Virginia Balseiro
  • Jeff Waters

Introductions

  • EJ: Have attended meetings already. Work at BitFocus as interoperability ??? Open source project looking to collaborate.

Topics

  • SC: Today's topics are intended for awareness and build engagement as opposed to solving technical details here.

Agenda and Minutes

Add PB profile shape for discussion

URL: solid/webid-profile#79

  • SC: VB will describe.
  • VB: This PR adds the ShEx shape used in PodBrowser to kick off the discussion (although we will use SHACL, this is just to have a starting point). Comments are welcome.
  • SC: Solid WebID Profile spec is trying to work its data model. With that we need to look at the cardinalities. A couple of issues linked to the PR as some topics have been already been discussed. The SHACL shape will eventually be one way of communicating the cardinality that the spec will describe.
  • SC: solid/webid-profile#26
  • SC: Planning to process each rule?
  • VB: If anything stands out, great to have comments.
  • EP: With respect to https://github.com/solid/webid-profile/pull/79/files#diff-2c97825c8bb9e1c6cdb6092b5daaef1639bf9013e52e8d05f2c1fd4a7798f335R119 is anyone working on trusted app draft? As that was just in old WAC draft.
  • VB: It is being taken into consideration. I am working on it at the moment.
  • SC: Related: solid/vocab#64
  • VB: Better to discuss trusted app in particular when we have a draft/proposal.
  • VB: There is also: solid/webid-profile#16
  • WT: Solid Profile shape is a person that has all the attributes, the current practice is we have a profile document that refers to a person, which then has the attributes. The convention currently is in a WebID Profile there's a statement that says "this doc is a profile, and the primary topic is a person", and then all the attributes are predicated of the person; whereas this Solid-PROFILE-Shape immediately considers a subject that is a person and has all the attributes.
  • SC: I think you raise something important and whether either one of those is required is part of this exercise of what that shape will look like. The general expectation is describing the WebID "thing" and the part about the primary topic of the personal profile doc is a glue that's added if you're describing a WebID.
  • WT: I don't think that it's necessary, but I would rename the shape to make it clear it is a person, not a profile.
  • SC: Can you add that add a comment to PR (WT)?

ACTION: WT to comment on PR

  • HS: One thing I noticed is that there's often "seeAlso" to a doc that is access controlled. This may need to be mentioned.
  • SC: If it's not there and it should be then you might need an action.
  • HS: grumbles

ACTION: HS to comment on the PR.

  • eP: I agree. I will put all details on PR. The profile is focused on the individual. Is there a plan to have it for organizations? Both are agents/denoted by WebIDs.
  • SC: There has been discussions on expressing things other than a person, orgs. Right now we might be able to capture on the current profile spec, not sure there's a need for a separate doc. It will definitely cover orgs. And groups.
  • eP: There's also conversations to denote applications.
  • SC: Alright. That's all good, that's all in the scope.

ACTION: eP to comment that on the PR. Maybe suggest links with existing vocabs.

  • SC: foaf:Agent covers "living things" (people, orgs, social entities) not software agents.
  • eP: org vocab is subclassing foaf:Agent
  • SC: there's nothing in foaf covering software.
  • HS: The foaf spec says of foaf:Agent that it is a class of "things that do stuff". The examples then clearly hint that those are intentional doings, not purely causal ones like the wind causing the movement of the trees. From the html doc:

    The foaf:Agent class is the class of agents; things that do stuff. A well known sub-class is foaf:Person, representing people. Other kinds of agents include foaf:Organization and foaf:Group.

  • SC: Correction to above as I was mistaken. I was conflating with no specific subclass of foaf:Agent for software but it is already covered in the RDF vocab:
  • SC: <http://xmlns.com/foaf/0.1/Agent> <http://www.w3.org/2000/01/rdf-schema#comment> "An agent (eg. person, group, software or physical artifact)." .
  • SC: In past meetings we discussed acl:client or acl:agent to refer to clients ( solid/web-access-control-spec#81 ). I mentioned things that would be necessary to use acl:agent as an existing property, but the definition in natural language might need to be updated. Good news that foaf:Agent already covers it. It's feasible to just have acl:agent provided we update. acl:agent has range foaf:Agent only description doesn't cover agent. Mechanically it's fine.
  • HS: what this ShEx is doing is for person. you can have one for software agents and organizations. And these would have different shapes.

Social profile as discovery mechanism

URL: solid/webid-profile#65

  • SC: Topic proposed by WT.
  • WT: I brought up that issue to indicate something that i find a bit strange and will influence data discovery.
  • WT: When we see a WebID profile doc, as used today, there's stuff that's in the shape we discussed today: names, addresses, etc. But on the other hand, we are defining mechanisms to let apps discover our data. For example, we have type indexes to point to where certain types of data are stores, and we have interop spec doing something similar with shape trees. My issue with this is that once you start adding data to the profile doc, it is either duplicate data that is discoverable via other discovery mechanisms, in which case it has to be kept in sync, or only available in that profile doc, so the question is what data should be stored where? if I'm an app and I want your address, your photo album, etc., do I look in your profile or use type indexes or interop registries? My intuition is that the profile document itself shouldn't contain any data, only pointers for discovery. That solves issues of duplicate data and where to find.
  • eP: I agree. Especially when we think about AuthZ, one case when data is public or protected info. The paper of Ruben Verborgh and team (ref???) using the case of birthday and so on; it is similar to email address — sometimes you want to share full name, first name, etc., and sometimes you want to make everything public. For that information AuthZ should happen before discovery. +1 to take advantage of existing discovery mechanisms to discover data. For different audiences you can select different vCards they have access to, instead of blindly trying every seeAlso. We need to work around some use cases from Ruben's paper and see how it can work, have different proposals. In general, I agree discovery needs to be taken into, and preceded with AuthZ for protected information.
  • DB: Last time in the WebID meeting, I remember Tim saying he was interested in having the possibility of a minimum profile. Name, pictures, things apps would consume in a daily basis. Reduce amount of hops for this popular information. Could there be a distinction of priorities in data?
  • SC: That's an old design pattern that has been in Solid. Just to make it useful. We're talking about Social linked data, the basics, even if it's a pseudonym, it puts something on a screen. If people want to put their real photo in a different location, that's fine. There's a distinction between making some info available for the utility of it, not so much exposing it. You can have anonymous and pseudonymous WebIDs.
  • WT: I agree that it is important that apps can access important information quickly. But I'd like to raise: it is quite naive to think that we know what apps will need now or in the future. Even if we decide it's a good idea to have these things, I think they should be in there using some mechanism that relies on the standard discoverable place where they are. You can imagine we store all data, even names and avatars, in the interop registries, but we let the authz agent/server of interop make it so that if you declare that a certain type of data is public, then ??? is added to your WebID profile. Just brainstorming.
  • HS: I think we should also be careful about premature optimization in this case. The argument that following links might be problematic because it might lead you nowhere, that's something you can deal with but expensive. You can have a version 2 of Solid that allows you to specify filters, it could be really complicated, because we're working on consensus... ??? we def could do that, but it's going to take a long time and resources to build. If we look at Mastodon, it's got public profiles. You can put your picture up... so we def wanna get to the point of military-grade security, but let's avoid tying ourselves into knots. Let's not build security again, that's it.
  • SC: We do have an understanding that if we can have a solution that you can extend to a point where you can have the basic thing now and leave enough space to solve that part later... without breaking changes... sometimes we're looking for a balance.
  • eP: +1 to avoiding premature optimization. We need some grounds before we start improving.
  • eP: We need to work based on combined use cases. I think about social graph use cases, because then we have authz and security considerations. We have address book and agent registry in SAI, and we need a consistent way of working and presenting information. We need, for example, to prevent phishing because of people impersonating others. When it comes to social graph, There are some issues on github related to working with info about individuals, especially on contacts later used for authorization.
  • SC: Let's pause. We can continue on WebID-Profile meeting on Tuesdays at 16:00UTC.

Quick note on Mastodon

Storage Description

URL: https://solidproject.org/ED/protocol#server-storage-description

  • SC: On discovery of storage description resource via http://www.w3.org/ns/solid/terms#storageDescription

  • SC: Background: #355

  • SC: Currently also used to discover information about Notification Channels: https://solid.github.io/notifications/protocol#server-link-storage-notification-channel

  • SC: but.. we need solid implementation feedback. Commitment to implement.

  • SC: A high overview: In the editor's draft we have a link to a requirement (link?) issue #355. If you haven't seen it please do.

  • SC: The term is proposed to be in Solid Terms vocabulary. Proposing to include the property to describe the storage description in the Notifications Protocol. We're saying that when a client wants to find out information about notification channel, there are two ways: one is through storage description. We agreed we will keep that in the notifications protocol spec; now it remains there and published eventually. If that changes, we will need to consider another way. Raising as topic because it's part of the Protocol where there's uses; on paper it sounds great, but that is not always enough to keep it in the spec, specially an ED. A good signal would be to have multiple implementations, or come up with an alternative proposal that meets the same use cases. Hoping that if you haven't come across it you'd give it a look. Relatively easy to implement, but we still need to see implementations (servers or applications) making use of that discovery, or a commitment to implement. Signals of that sort are important. Even if you say this makes no sense, that's as useful as commitment to implement. That's how we know if it needs to be on the spec. When we have tests for these things and need to show implementation reports, the results will show whether that particular implementation agreed to use that, and if not implemented, we can remove from the spec. That's why we go through this process. That goes for any feature or solutions that we have in the spec. If no one will implement a certain feature, we need to focus on low hanging fruit.

Considerations section

URL: https://solidproject.org/ED/protocol#considerations

  • SC: An overview about this section and request for comments.

Forming a W3C Solid Work Group

URL: https://lists.w3.org/Archives/Public/public-solid/2022Nov/0001.html

  • SC: If TimBL present...