or
or
By clicking below, you agree to our terms of service.
New to HackMD? Sign up
Syntax | Example | Reference | |
---|---|---|---|
# Header | Header | 基本排版 | |
- Unordered List |
|
||
1. Ordered List |
|
||
- [ ] Todo List |
|
||
> Blockquote | Blockquote |
||
**Bold font** | Bold font | ||
*Italics font* | Italics font | ||
~~Strikethrough~~ | |||
19^th^ | 19th | ||
H~2~O | H2O | ||
++Inserted text++ | Inserted text | ||
==Marked text== | Marked text | ||
[link text](https:// "title") | Link | ||
 | Image | ||
`Code` | Code |
在筆記中貼入程式碼 | |
```javascript var i = 0; ``` |
|
||
:smile: | ![]() |
Emoji list | |
{%youtube youtube_id %} | Externals | ||
$L^aT_eX$ | LaTeX | ||
:::info This is a alert area. ::: |
This is a alert area. |
On a scale of 0-10, how likely is it that you would recommend HackMD to your friends, family or business associates?
Please give us some advice and help us improve HackMD.
Syncing
xxxxxxxxxx
W3C Solid Community Group: Weekly
Present
Announcements
Meeting Recordings and Transcripts
Participation and Code of Conduct
Scribes
Introductions
Topics
Agenda and Minutes
SC: Agenda is typically PRd at https://github.com/solid/specification/
SC: Reviews on the PR are welcome.
SC: Previous meeting's minutes are at https://github.com/solid/specification/blob/main/meetings/2022-11-09.md and you can always find prior minutes at https://github.com/solid/specification/blob/main/meetings/.
SC: Please note that unless there is a decision to change the meeting datetime, it is always on UTC time (and daylight savings time is not observed, as it stands).
SC: Please speak clearly and slowly to help with transcribing.
SC: Editorial help with transcription is welcome, e.g., where scribe marks
???
, adding links, fixing grammar, or typos. However, do not change or elaborate on earlier transcription, especially what was not explicitly "aired" by the group.Add PB profile shape for discussion
URL: https://github.com/solid/webid-profile/pull/79
ACTION: WT to comment on PR
ACTION: HS to comment on the PR.
ACTION: eP to comment that on the PR. Maybe suggest links with existing vocabs.
foaf:Agent
<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)."
.acl:client
oracl:agent
to refer to clients ( https://github.com/solid/web-access-control-spec/issues/81 ). I mentioned things that would be necessary to useacl:agent
as an existing property, but the definition in natural language might need to be updated. Good news thatfoaf:Agent
already covers it. It's feasible to just haveacl:agent
provided we update.acl:agent
has rangefoaf:Agent
only description doesn't cover agent. Mechanically it's fine.Social profile as discovery mechanism
URL: https://github.com/solid/webid-profile/issues/65
Quick note on Mastadon
https://mathstodon.xyz/@bblfish/109326189343436621
https://github.com/bblfish/authentication-panel/blob/main/proposals/HttpSignature.md
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: https://github.com/solid/specification/issues/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. What we're saying is when a client wants to find out information about notification channel, 2 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 needs 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
Forming a W3C Solid Work Group
URL: https://lists.w3.org/Archives/Public/public-solid/2022Nov/0001.html