Skip to content

Use 'public' not 'listed' in comments. Implement Boolean range for . #57

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 5 commits into
base: main
Choose a base branch
from

Conversation

timbl
Copy link
Contributor

@timbl timbl commented Sep 21, 2021

Trying to phase out "Listed" and "Unlisted" as words for "Public" and "Private".

Implement a range statement which was already in the comments.

dc:issued "2018-01-24"^^xsd:date ;
rdfs:comment "Points to an unlisted type index resource."@en ;
rdfs:comment
"""The object is to a private (unlisted) type index resource.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
"""The object is to a private (unlisted) type index resource.
"""The object is a private (unlisted) type index resource.

rdfs:subPropertyOf solid:typeIndex ;
rdfs:comment "Points to a listed type index resource."@en ;
rdfs:comment """The object is to a pubic ("listed") type index resource..
Copy link
Contributor

@TallTed TallTed Sep 24, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
rdfs:comment """The object is to a pubic ("listed") type index resource..
rdfs:comment """The object is a pubic ("listed") type index resource.

@@ -0,0 +1,6 @@
Copyright 2019 - present
Copy link
Contributor

@TallTed TallTed Oct 1, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
Copyright 2019 - present
Copyright 2019 - 2022 _ENTITY_
  • present is not valid in a copyright statement; specific year(s) must be listed
  • the entity claiming copyright must be identified, historically/typically with a human-focused name, potentially including or changing to a machine-focused URI such as a WebID or DID which may be dereferenced to machine- or human-focused details (a/k/a RDF)

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Re entity URI, let's revisit this after resolving solid/specification#412 and if still applicable.

@jeff-zucker
Copy link
Member

We need a third term "restricted". If I have a seeAlso file only accessible to three people and I list it in my public profile, it isn't really a "public" resource. It is publicly discoverable (listed), but only three people can access it. I've noticed confusion over this in the the forum and chats - people assume that a resource restricted to three people is "private", not "public".

@@ -0,0 +1,8 @@


alcs:
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
alcs:
acl:

@@ -0,0 +1,6 @@
Copyright 2019 - present
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Making the following suggestion since we use it elsewhere for code/spec:

Suggested change
Copyright 2019 - present
Copyright 2019 - 2022 W3C Solid Community Group

But may be worth questioning whether the CG should hold the copyright on the repo or another entity.

We included some non-Solid-centric vocabs in this repo so to have open contributions and simplify the update process.

rdfs:subPropertyOf solid:typeIndex ;
rdfs:comment "Points to a listed type index resource."@en ;
rdfs:comment """The object is to a pubic ("listed") type index resource..
The subject is the user's webid.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
The subject is the user's webid.
The subject is the user's WebID.


solid:read
a rdf:Property ;
dc:issued "2015-12-18"^^xsd:date ;
rdfs:comment "Indicates if a message has been read or not. This property should have a boolean datatype."@en ;
rdfs:isDefinedBy <http://www.w3.org/ns/solid/terms#> ;
rdfs:domain <http://rdfs.org/sioc/ns#Post> ;
rdfs:range xsd:boolean;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
rdfs:range xsd:boolean;

That can be introduced in a separate PR about solid:read.

Aside: domain sioc:Post is not particularly interesting. (Nowadays messages/notifications tend to be an as:Activity of some kind.)

Comment on lines +211 to +212
The triple in found in the private preferences file.
(which itself is pointed to from the public profile by space:preferencesFile)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
The triple in found in the private preferences file.
(which itself is pointed to from the public profile by space:preferencesFile)
The triple in found in the private preferences file
(which is pointed to from the public profile by space:preferencesFile).

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

better --

Suggested change
The triple in found in the private preferences file.
(which itself is pointed to from the public profile by space:preferencesFile)
The triple in found in the private preferences file
(to which the public profile points, using space:preferencesFile).

@melvincarvalho
Copy link
Member

Much prefer:

PublicDocument to ListedDocument
PrivateDocument to UnlistedDocument

It's intuitive and matches other things we have. Will implement this if it's still the plan?

Comment on lines +199 to +200
The triple in found in the private preferences file.
(which itself is pointed to from the public profile by space:preferencesFile)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
The triple in found in the private preferences file.
(which itself is pointed to from the public profile by space:preferencesFile)
The triple in found in the private preferences file
(to which the public profile points, using space:preferencesFile).

@melvincarvalho
Copy link
Member

We discussed this PR during the last Solid CG call. I have left a meta comment here.

Let's try and get PublicDocument and PrivateDocument over the line, as I think it's going to be an important shape for app discovery.

@elf-pavlik
Copy link
Member

https://github.com/solid/type-indexes draft report doesn't seem active, still I think it would be important to check with editors if they still plan to work on it or someone else needs to step up.

@melvincarvalho
Copy link
Member

@elf-pavlik +1

I could potentially work on this as I have been working on a type index app.

But I would prefer to coordinate with the chairs and ODI, and see if @timea-solid still wants to be an active editor.

image

rdfs:comment "Points to an unlisted type index resource."@en ;
rdfs:comment
"""The object is to a private (unlisted) type index resource.
The subject is the user's webid.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
The subject is the user's webid.
The subject is the user's WebID.

@TallTed
Copy link
Contributor

TallTed commented May 30, 2025

@melvincarvalho

PR #57 was originally submitted on September 21, 2021, and has had suggested changes since September 24, 2021, which suggestions have not been responded to (whether by acceptance, discussion, or otherwise) by the PR originator, @timbl.

Additionally, in the almost four years since changes were first requested on this PR, there have, unsurprisingly, been many commits to the main branch against which this PR is targeted, resulting in conflicts between this PR and that target branch. These conflicts must be resolved, typically by the originator of the PR, before the PR can be merged. (I do not have permissions enabling me to resolve the conflicts, so GitHub does not even provide me with the URL leading to the conflict resolution UI, so I cannot provide it to you.)

Until suggested/requested changes have been acted on (again, whether accepted, discussed, or otherwise), no PR should progress, regardless of whether some specific reviewers have approved it. Such specific reviewers never achieve perfection when reviewing PRs, and typos and other errors may slip past them, no matter how hard they strive for such perfection. Benefiting from such change requests from other people is one of the reasons to embrace Open Source ideals.

All of which is to say, the logjam on this PR starts with its originator, i.e., with @timbl.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

7 participants