solid/specification

Repository: https://github.com/solid/specification - Technical Reports: https://solidproject.org/TR/ - Code of Conduct: https://github.com/solid/specification#code-of-conduct

Sarven Capadisli

@csarven

<http://www.w3.org/ns/auth/acl#owner> <http://www.w3.org/1999/02/22-rdf-syntax-ns#type> <http://www.w3.org/1999/02/22-rdf-syntax-ns#Property> .
<http://www.w3.org/ns/auth/acl#owner> <http://www.w3.org/2000/01/rdf-schema#comment> "The person or other agent which owns this.\n    For example, the owner of a file in a filesystem.\n    There is a sense of right to control.   Typically defaults to the agent who craeted\n    something but can be changed." .
<http://www.w3.org/ns/auth/acl#owner> <http://www.w3.org/2000/01/rdf-schema#label> "owner"@en .
<http://www.w3.org/ns/auth/acl#owner> <http://www.w3.org/2000/01/rdf-schema#range> <http://xmlns.com/foaf/0.1/Agent> .

is the the namespace that's of concern?

Aaron Coburn

@acoburn

yes

Sarven Capadisli

@csarven

so I don't understand the question then.. do you want a property for ACP (which you've already put through under w3.org..)

Want a more generic eg. solid:owner / solid:podOwner etc?

Aaron Coburn

@acoburn

The question is: does every authZ mechanism define their own owner property, or can one be added to the solid namespace and thereby be more generally applicable?

Sarven Capadisli

@csarven

I don't know about every.. but WAC doesn't require it at the moment, as you know. There are some things that's hinting at using acl:owner (or something similar from what I've gathered) but that's not specified. I do think it is reasonable to put it under solid/terms.

Aside: This conversation makes me think of WAC-Allow's parameters and access modes.

Aaron Coburn

@acoburn

Aside: This conversation makes me think of WAC-Allow's parameters and access modes.

completely agree

Sarven Capadisli

@csarven

So, if solid:owner is equivalentProperty acl:owner that'd be okay? :) IMO, for "podOwner" to be sensible, domain probably needs to be a "Pod". This is where I was going with using acl:owner on pim:Storage.

Justin Bingham

@justinwb

The question is: does every authZ mechanism define their own owner property, or can one be added to the solid namespace and thereby be more generally applicable?

should be under solid imo

Dmitri Zagidulin

@dmitrizagidulin

any chance i can convince ya’ll to use ‘controller’ instead of ‘owner’?

(so that we can match the w3c community terminology)

Matthieu Bosquet

@matthieubosquet

@dmitrizagidulin could you link to relevant documentatoin on the w3c terminology?

Matthieu Bosquet

@matthieubosquet

+1 for the owner/controller property being under solid with domain solid:Pod
Sorry if the question has already been answered, but is there or should we create a class and predicate for WebIDs?
Something like solid:webId & solid:WebID.
Since really agents in the solid context are identified by a WebID and a WebID really is just a URI identifying an Agent.
I'm wondering if solid:WebID would not be a better fit as range of an owner property or as domain of solid:oidcIssuer instead of a vcard:Agent which might have a solid:webId or not.

Sarven Capadisli

@csarven

@matthieubosquet If of interest: https://github.com/solid/specification/issues/153#issuecomment-616464435 , https://gitter.im/solid/chat?at=59f890fce44c43700a9dc81f or see links in https://github.com/solid/contacts-pane/issues/18#issuecomment-725963009 .

As long as the needs are well documented and specs are referring to them, all fine. Not sure about a webid Class but can probably get more out of a property.

I'm not opposed to "podOwner" property or "Pod" class -- and which namespace is to throw it under is the least of concerns IMO -- but I'd like to hear more from people about what they think/expect with the differences are with root container (pim:Storage) or maybe even server origin or root URI path..

re "controller" or "owner" etc .. see links above. Plenty of existing discussion in chats/issues.. not worth repeating here unless there is some new information. tl;dr: both are fine as synonyms but can obviously differ in their meaning and purpose. Don't forget to throw in "creator" or "admin" or "authority" for fun and profit.

Matthias Evering

@ewingson

Don't forget to throw in "creator" or "admin" or "authority" for fun and profit.

I like this thought. it made me smile...

@csarven do you need confirmation for participation in the w3c meetings ? I won' t make it on feb 22nd but on march 10th I will attend both as fly on the wall.

Sarven Capadisli

@csarven

@ewingson No need now.. just attend as you can/like. Thanks.

Justin Bingham

@justinwb

@csarven is this meeting still happening?

i’m at https://meet.jit.si/solid-wicg-identity-authentication but there’s no one else here

Justin Bingham

@justinwb

ah is it 5 hours from now

Sarven Capadisli

@csarven

Fred Gibson

@gibsonf1

Is there a preferred language predicate to use for setting a user's language?

there is this, but not quite the right thing: https://schema.org/knowsLanguage

Dev380

@Dev380

Hello. I have a few questions about Solid:
1) So, traditionally data is stored by the platform, and you have to trust them with your data and the ability to download your data, etc. But with Solid, you have to trust the pod. Isn't this just moving the problem a level back? 2) Most people are too lazy to make new pods for every app, so then wouldn't a chess website know your name (for example) in Solid but not in the traditional model? 3) What if a Solid app just downloads the data off your pod each time you use it?

Henry Story

@bblfish

Security, like knowledge is not an all or nothing matter. You need many different pieces of the puzzle to fit together.

But you can progress towards better architectures.

Sarven Capadisli

@csarven

@gibsonf1 I think we discussed "preferred language" somewhere but can't find it off hand now - if you come across it, let me know. It is along the lines of "preferred license" that can be used as part of a pim:configurationFile or something else ( solid/vocab#6 ). It can guide the application. I'd suggest to be clear .. is the intent to tell the User Agent (eg Accept-Language) - and whether that should just be controlled by the UA, so not a problem to solve here - or application internationalisation (software to adapt to user's preferred language) eg: https://github.com/linkeddata/dokieli/issues/242#issuecomment-409504926 .

You may also want to note the Cognitive Characteristics Ontology: http://smiy.sourceforge.net/cco/spec/cognitivecharacteristics.html . I use cco:skill here: https://csarven.ca/cv

Sarven Capadisli

@csarven

Made a minor update to use ESCO's language skills ( http://data.europa.eu/esco/skill/L ). Fun.

Fred Gibson

@gibsonf1

@csarven impressive!

Henry Story

@bblfish

Does Solid distinguish between a URL ending with / and the same one minus the /? What is the difference in terms of files on the file system? It looks like it does according to the node-solid resource mapper.

I see that It looks like https://an.example/foo requested with text/html would return resource https://an.example/foo.html whereas https://an.example/foo/ could return foo/index.html if the default for a dir is set to index.html

Henry Story

@bblfish

Is that specified, or is that a node-solid choice? I guess the idea is that foo.html is the external view of the container, and foo/index.html the internal view of the container.

Sarven Capadisli

@csarven

@bblfish Container and contained resources can be distinguished. If /foo exists, /foo/ can't exist, and vice versa. It doesn't say anything the URI (Template) for representation URLs https://solidproject.org/TR/protocol#uri-slash-semantics

so, servers can use Content-Location if they want to.

Henry Story

@bblfish

If two URIs differ only in the trailing slash, and the server has associated a resource with one of them, then the other URI MUST NOT correspond to another resource.

that seems to say the opposite.

Behaviour pertaining to authorization MUST proceed this optional redirect

that is bad english. I am not sure what that means.

Should I open an issue?

Sarven Capadisli

@csarven

If /foo/ exists and server implements redirecting (eg. /foo to /foo/), then when /foo is requested, redirect should only happen if agent is authorized to know about the existence of /foo/. If it doesn't implement redirect, 403 will be returned (or returning 404 if agent can read /)

I think we can rephrase that... I think it should move into security considerations because it is not unique to slash stuff

IIRC, Tim wasn't keen on having a MAY for the redirect. I think I said we can lowercase it

Henry Story

@bblfish

I opened an issue to capture the problem. solid/specification#240

I think you meant must preceed (i.e., come beforehand) not must proceed (must do).

Jordan Shurmer

@JordanShurmer

@bblfish URL ending with a / will be containers. It's defined in the spec somewhere. one sec

Oh.. I see there was already discussion about it :D sorry

@Dev380 Yes what you bring up is still a reality that needs to be dealt with in various ways. I.e. if you, as a user, don't trust an app then you should not give it permission to access your data. Solid has no way of limiting what they do with your data once they access it.

However, IMO Solid gives encourages apps to build trust with their users (e.g. publish their source code so we know what they're doing). Maybe some day there would be various ways to build trust into the system to

Where communities thrive

People

Repo info

Activity