Linked Web Storage 사용 사례

LWS 명세를 위한 사용 사례는 아래에 문서화되어 있습니다.

범용 저장소

사용자로서, 나는 모든 유형의 리소스를 지원하는 형식에 구애받지 않는 온라인 저장소 시스템을 원합니다. 그렇게 함으로써 모든 장치에서 언제든지 메타데이터와 접근 제어 수정뿐 아니라 이전 버전 복구를 포함한 생성, 읽기, 갱신 및 삭제(CRUD)를 수행할 수 있습니다. 맥락: 이는 장치 전반에서 원활한 데이터 관리를 보장하여 사용자가 자신의 리소스를 완전히 제어할 수 있게 합니다.
이슈: #117, #97, #60, #63, #62, #69
이식 가능한 저장소

사용자로서, 나는 내 저장소를 직접 호스팅하거나 데이터를 잃지 않고 제공자 간에 전환할 수 있는 능력을 원합니다. 그렇게 함으로써 데이터 주권을 유지하고 데이터 손실 없이 제공자 장애나 이전을 견딜 수 있습니다. 맥락: 이식성은 벤더 종속을 방지하고 데이터 주권을 강화합니다.
이슈: #30, #58, #140, #61
오프라인 데이터 접근

사용자로서, 나는 오프라인에서 내 데이터에 접근하고 수정하며, 재연결 시 자동 동기화되기를 원합니다. 그렇게 함으로써 네트워크 없이도 작업하고 데이터 손상이나 충돌을 피할 수 있습니다.
맥락: 오프라인 지원은 연결성이 불안정한 지역의 사용자에게 매우 중요합니다.
이슈: #138, #64, #65, #67
대용량 파일 업로드

사용자로서, 나는 재개 가능한 업로드로 대용량 파일을 업로드하길 원합니다. 그렇게 함으로써 중단이 전체 전송을 처음부터 다시 시작하도록 만들지 않게 할 수 있습니다.
맥락: 이는 대용량 미디어 또는 데이터 파일 관리를 위한 사용성을 향상시킵니다.
이슈: #18

접근 공유

데이터 소유자로서, 나는 내 리소스에 대한 세분화된 권한을 부여하고 취소할 수 있기를 원합니다. 그렇게 함으로써 협업자에게 적절한 접근 권한을 부여하고, 그들의 권한이 변경될 때 알림을 받을 수 있습니다. 맥락: 세분화된 제어는 안전하고 맞춤화된 데이터 공유를 보장합니다.
이슈: #7, #27, #116, #148, #120, #98
권한 변경에 대한 알림

협업자로서, 나는 리소스에 대한 내 권한이 부여, 취소 또는 수정될 때 알림을 받기를 원합니다. 그렇게 함으로써 내 접근 권한의 변경 사항을 적시에 알 수 있습니다. 맥락: 적시 알림은 협업자가 공유 리소스에 대한 자신의 접근 상태를 최신으로 유지하도록 도와 협업과 보안을 향상시킵니다. 이슈: #116, #78
프로필 공유

사용자로서, 나는 서로 다른 접근 제어를 가진 여러 프로필을 유지하고 싶습니다. 그렇게 함으로써 특정 정보를 공유하면서 다른 데이터는 비공개로 유지할 수 있습니다. 맥락: 여러 프로필은 서로 다른 페르소나나 맥락(예: 업무 vs. 개인)을 지원합니다.
이슈: #29, #57
그룹 공유

사용자로서, 나는 동적 그룹(예: 이벤트 참석자)과 데이터를 공유하길 원합니다. 그렇게 함으로써 그룹이 변화함에 따라 멤버십과 권한이 자동으로 갱신될 수 있습니다.
맥락: 이는 임시 또는 변화하는 협업의 접근 관리를 단순화합니다.
이슈: #38, #102
행정 보조자

사용자로서, 나는 보조자에게 특정 권한을 위임하고 감사 로그로 그들의 작업을 추적하길 원합니다. 그렇게 함으로써 그들이 나를 대신해 내 데이터를 안전하게 관리할 수 있습니다.
맥락: 위임은 감독을 유지하면서도 도움이 필요한 사용자를 지원합니다.
이슈: #10, #104, #118
맥락 인식 접근 정책

관리자로서, 나는 시간, 지리적 위치 또는 상대적 위치(Bob 근처)와 같은 맥락 요소를 기반으로 접근 정책을 시행하길 원합니다. 그렇게 함으로써 데이터 접근이 실제 조건에 따라 동적으로 조정될 수 있습니다.
맥락: 맥락 인식 정책은 보안과 유연성을 향상시킵니다.
이슈: #17, #147, #94
건강 기록 접근

환자로서, 나는 위임된 권한 부여를 사용하여 특정 건강 기록을 AI 보조자와 공유하길 원합니다. 그렇게 함으로써 책임성을 보장하는 감사 로그와 함께 2차 의견을 얻을 수 있습니다.
맥락: 이는 정보에 기반한 결정을 위해 안전하고 감사 가능한 건강 데이터 공유를 지원합니다.
이슈: #11, #46, #54

회의 일정 잡기

사용자로서, 나는 온라인 및 오프라인 시나리오에 대한 충돌 감지와 함께 내 저장소를 통해 직접 회의 일정을 잡고 싶습니다. 그렇게 함으로써 이중 예약을 피할 수 있습니다.
맥락: 통합된 일정 관리는 생산성과 조율을 향상시킵니다.
이슈: #3, #42
실시간 알림

협업자로서, 나는 내가 접근하는 리소스가 갱신될 때 실시간 알림을 원합니다. 그렇게 함으로써 수동 확인 없이 최신 정보를 유지할 수 있습니다.
맥락: 적시 갱신은 협업 효율성을 향상시킵니다.
이슈: #32, #79
애플리케이션 알림

사용자로서, 나는 저장소 활동에 대해 이메일 또는 웹 푸시 알림을 원합니다. 그렇게 함으로써 중요한 이벤트를 계속 인지할 수 있습니다.
맥락: 알림은 사용자가 자신의 데이터에 지속적으로 관여하도록 합니다.
이슈: #100
범용 커뮤니케이션

사용자로서, 나는 다른 저장소 소유자와 직접 메시징 채널을 갖고 싶습니다. 그렇게 함으로써 플랫폼 내에서 원활하게 협업할 수 있습니다.
맥락: 내장 커뮤니케이션은 사용자 상호작용을 강화합니다.
이슈: #99, #22
투표

사용자로서, 나는 내 저장소 내에서 투표를 만들고 관리하고 싶습니다. 그렇게 함으로써 다른 사람들로부터 의견과 피드백을 수집할 수 있습니다.
맥락: 투표는 의사 결정과 커뮤니티 참여를 지원합니다.
이슈: #144
시맨틱 협업

사용자로서, 나는 영구 URI와 유연한 권한을 사용하여 다른 사람들과 구조화된 콘텐츠를 공동 작성하고 싶습니다. 그렇게 함으로써 협업을 효율적이고 추적 가능하게 만들 수 있습니다.
맥락: 이는 공유 지식 기반과 같은 고급 사용 사례를 가능하게 합니다.
이슈: #146, #98

개인 정보 관리

사용자로서, 나는 내 저장소에서 개인 데이터를 관리하고, 일부 데이터 변환을 통해 비-Solid 앱과 통합하고 싶습니다. 그렇게 함으로써 데이터 사일로를 만들지 않고 다양한 앱을 사용할 수 있습니다.
맥락: 이는 상호운용성과 사용자 제어를 촉진합니다.
이슈: #2
'Bring Your Own Data' 앱

앱 개발자로서, 나는 내 애플리케이션이 CRUD 작업과 저장소 발견 지원과 함께 사용자의 저장소에 데이터를 저장하길 원합니다. 그렇게 함으로써 사용자가 자신의 데이터에 대한 소유권과 제어권을 유지할 수 있습니다.
맥락: 이는 데이터 소유권을 앱에서 사용자로 이동시킵니다.
이슈: #12, #120
디지털 상품 전달

사용자로서, 나는 확인 영수증과 함께 디지털 상품(예: 소프트웨어, 미디어)을 안전하게 전달받길 원합니다. 그렇게 함으로써 제공자가 최소한의 개입으로 자산을 전달할 수 있습니다.
맥락: 이는 신뢰할 수 있는 디지털 제품 전달을 보장합니다.
이슈: #14
데이터 통합

앱 개발자로서, 나는 여러 소스의 데이터를 결합하기 위한 표준화된 API를 원합니다. 그렇게 함으로써 다양한 데이터셋을 통합하는 것이 간단하고 효율적이 됩니다.
맥락: 단순화된 통합은 개발 복잡성을 줄입니다.
이슈: #26, #53, #88, #106
비즈니스 데이터 접근

비즈니스 사용자로서, 나는 데이터 공유에 대한 명확한 시행 규칙을 원합니다. 그렇게 함으로써 엔터프라이즈 통합이 조직 정책을 준수할 수 있습니다.
맥락: 이는 안전한 엔터프라이즈 사용 사례를 지원합니다.
이슈: #27, #28

시계열 저장소

사용자로서, 나는 해상도 제한과 다차원 분석 지원을 갖춘 시계열 데이터를 저장하고 싶습니다. 그렇게 함으로써 시간에 따른 추세를 효율적으로 분석할 수 있습니다.
맥락: 이는 IoT 또는 분석과 같은 애플리케이션에 중요합니다.
이슈: #6
센서 데이터 공유

사용자로서, 나는 중복 없이 다양한 세분화 수준으로 센서 데이터를 공유하고 싶습니다. 그렇게 함으로써 소비자가 필요한 세부 정보만 받을 수 있습니다.
맥락: 효율적인 공유는 리소스 사용량을 줄입니다.
이슈: #8
법적 보고

데이터 제공자로서, 나는 감사 준수를 지원하기 위해 데이터 공유의 검증 가능한 증거를 원합니다. 그렇게 함으로써 접근이 취소된 후에도 법적 의무를 충족할 수 있습니다.
맥락: 이는 투명성과 책임성을 보장합니다.
이슈: #9
검색 기능

사용자로서, 나는 맥락 인식 및 보안 시행을 갖춘 강력한 검색 기능을 원합니다. 그렇게 함으로써 관련 리소스를 빠르고 안전하게 찾을 수 있습니다.
맥락: 효과적인 검색은 대규모 데이터셋에 필수적입니다.
이슈: #152, #87
페이지 매김 및 필터링

사용자로서, 나는 검색 결과의 효율적인 페이지 매김, 필터링 및 정렬을 원합니다. 그렇게 함으로써 대규모 데이터셋을 쉽게 탐색할 수 있습니다.
맥락: 이러한 기능은 데이터 사용성을 향상시킵니다.
이슈: #103
SPARQL 쿼리

파워 유저로서, 나는 복잡한 검색과 데이터 분석을 수행하기 위해 SPARQL 쿼리 지원을 원합니다. 그렇게 함으로써 연결된 데이터에서 통찰을 추출할 수 있습니다.
맥락: SPARQL은 고급 시맨틱 웹 쿼리를 가능하게 합니다.
이슈: #45
웹사이트 생성

사용자로서, 나는 영구 URI를 가진 자기 설명적 웹사이트를 게시하고 싶습니다. 그렇게 함으로써 내 콘텐츠가 시간이 지나도 접근 가능하고 상호운용 가능하게 유지됩니다.
맥락: 이는 지속 가능한 웹 게시를 지원합니다.
이슈: #31
가정 접근

사용자로서, 나는 동적 IP를 가진 가정용 장치에서 내 저장소에 접근하고 싶습니다. 그렇게 함으로써 연결 문제가 내 데이터 사용을 막지 않도록 할 수 있습니다.
맥락: 이는 가정 환경에서의 접근성을 보장합니다.
이슈: #105, #68
맥락적 상호작용

사용자로서, 나는 콘텐츠와 함께 상호작용을 맥락에 맞게 표시하길 원합니다. 그렇게 함으로써 권한과 이력을 직관적으로 이해할 수 있습니다.
맥락: 이는 데이터 상호작용에 대한 사용자의 이해를 향상시킵니다.
이슈: #55
WebID 프로필 상호작용

사용자로서, 나는 WebID를 클릭하면 프로필과 사용 가능한 작업이 표시되길 원합니다. 그렇게 함으로써 연락처와 쉽게 상호작용할 수 있습니다.
맥락: 이는 사회적 및 전문적 상호작용을 향상시킵니다.
이슈: #48, #47
저장소 감시

앱 개발자로서, 나는 저장소 변경 사항을 오프라인으로 모니터링하길 원합니다. 그렇게 함으로써 연결성이 없어도 내 애플리케이션이 동기화 상태를 유지할 수 있습니다.
맥락: 이는 견고한 오프라인 앱 기능을 지원합니다.
이슈: #101

'종단 간' 암호화

사용자로서, 나는 모든 데이터 저장과 전송에 대해 종단 간 암호화를 원합니다. 그렇게 함으로써 권한이 있는 당사자만 내 정보를 복호화하고 접근할 수 있습니다.
맥락: 암호화는 데이터 기밀성을 보장합니다.
이슈: #4, #44, #73, #74, #75, #76
동의 기반 공유

사용자로서, 나는 데이터 공유를 위한 검증 가능한 동의 메커니즘과 감사 추적을 원합니다. 그렇게 함으로써 개인정보 보호 규정 준수를 보장할 수 있습니다.
맥락: 동의 관리는 윤리적 데이터 관행을 지원합니다.
이슈: #141, #80, #81, #82, #83, #84, #85, #86
법적 근거 지원

준법 감시 담당자로서, 나는 법적 근거(예: GDPR)를 기반으로 접근 정책을 정의하길 원합니다. 그렇게 함으로써 데이터 공유가 규제 요구사항을 준수할 수 있습니다.
맥락: 이는 전 세계적인 준수 준비성을 보장합니다.
이슈: #80, #141, #77

저장소 소유권

사용자로서, 나는 저장소 생성 시 소유권이 할당되기를 원합니다. 그렇게 함으로써 처음부터 완전한 제어권을 가질 수 있습니다.
맥락: 즉각적인 소유권은 사용자의 권한을 명확히 합니다.
이슈: #43
고성능 접근 제어

사용자로서, 나는 반응성이 뛰어나고 확장 가능한 접근 제어 메커니즘을 원합니다. 그렇게 함으로써 시스템이 높은 부하에서도 잘 수행될 수 있습니다.
맥락: 성능은 대규모 사용에 매우 중요합니다.
이슈: #72, #153, #71
명확한 오류 메시지

사용자로서, 나는 명확하고 실행 가능한 오류 메시지를 원합니다. 그렇게 함으로써 문제를 빠르고 좌절 없이 해결할 수 있습니다.
맥락: 좋은 오류 처리는 사용자 경험을 향상시킵니다.
이슈: #34

신원 및 자격 증명 관리

사용자로서, 나는 내 신원과 자격 증명을 로컬에서 관리하고 싶습니다. 그렇게 함으로써 내 장치에서 직접 내 인증 프로세스를 제어할 수 있습니다.
맥락: 로컬 관리는 보안과 자율성을 강화합니다.
이슈: #25, #90, #115, #153, #128
인증 메커니즘

사용자로서, 나는 패스키, 무음 인증, 스크립트 친화적 옵션과 같은 최신 인증 방법에 대한 지원을 원합니다. 그렇게 함으로써 다양한 시나리오에서 안전하게 인증할 수 있습니다.
맥락: 유연한 인증은 다양한 사용자 요구를 충족합니다.
이슈: #39, #41, #49, #50, #51, #114, #162, #129, #130, #136
저장소 제공자를 위한 신뢰 메커니즘

저장소 제공자로서, 나는 엔터티 인증을 위해 신원 제공자를 신뢰할 수 있는 메커니즘을 원합니다. 그렇게 함으로써 인증되고 권한이 부여된 엔터티만 저장소에 접근하도록 보장할 수 있습니다.
맥락: 이러한 신뢰 관계는 여러 신원 제공자가 관여할 수 있는 분산 시스템에서 보안을 유지하는 데 중요합니다.
이슈: #129

API 프로토콜 분리

개발자로서, 나는 API가 HTTP와 분리되기를 원합니다. 그렇게 함으로써 로컬 우선 애플리케이션을 만들거나 gRPC 또는 GraphQL과 같은 대체 프로토콜을 사용할 수 있습니다.
맥락: 분리는 개발 유연성을 높입니다.
이슈: #24
백엔드 서비스 통합

서비스 제공자로서, 나는 백엔드 서비스를 위한 mTLS 또는 더 단순한 대안과 같은 안전한 인증 방법을 원합니다. 그렇게 함으로써 LWS와의 통합이 원활하고 안전해집니다.
맥락: 이는 신뢰할 수 있는 백엔드 연결성을 보장합니다.
이슈: #40, #56, #92
저장소 설명 및 발견

사용자 또는 애플리케이션으로서, 나는 사용 가능한 저장소와 서비스 역량에 대한 메타데이터를 검색하고 싶습니다. 그렇게 함으로써 상호작용을 적절히 구성하고 다양한 저장소 동작에 적응할 수 있습니다.
맥락: 서버 역량을 표준화된 방식으로 설명하면 클라이언트가 작업을 동적으로 조정할 수 있고, 상호운용성이 향상되며, 도구화 또는 자동화가 쉬워집니다.
이슈: #21

저장소 유연성

사용자로서, 나는 저장소 단위를 동적으로 분할하거나 집계할 수 있는 능력을 원합니다. 그렇게 함으로써 필요가 변화함에 따라 용량과 구성을 조정할 수 있습니다.
맥락: 유연한 저장소는 확장성과 사용자 지정을 지원합니다.
이슈: #110, #136, #127, #69, #70
하이퍼미디어 저작

개발자로서, 나는 하이퍼미디어 표현(예: JSON-LD, Siren)을 작성하기 위한 일관된 메커니즘을 원합니다. 그렇게 함으로써 클라이언트가 API를 일관되게 탐색하고 상호작용할 수 있습니다.
맥락: 표준화된 하이퍼미디어는 API 사용성을 향상시킵니다.
이슈: #33, #124

다음 요구사항은 위의 사용 사례를 충족하는 데 충분한 것으로 식별되었습니다. 이 문서는 비규범 문서이며, 워킹 그룹은 일부 요구사항이 범위를 벗어난다고 결정할 수 있습니다.

	1	2	3	6	7	8	9	10
범용 저장소		✓	✓		✓
이식 가능한 저장소		✓	✓	✓
접근 공유	✓		✓			✓	✓
프로필 공유	✓		✓			✓	✓
그룹 공유	✓		✓			✓	✓
행정 보조자	✓		✓			✓	✓
오프라인 데이터 접근	✓	✓						✓

저장소 내 리소스 추가, 갱신, 삭제 — 프로토콜은 권한이 부여된 엔터티가 저장소 내에 리소스를 추가, 갱신 및/또는 삭제할 수 있도록 해야 합니다. 일반적으로 프로토콜은 모든 유형의 리소스를 저장소에 저장할 수 있도록 해야 하지만, 저장소 제공자는 유형이나 크기와 같은 특정 제한을 부과할 수 있습니다.

이슈: #117, #124
스토리: 범용 저장소
데이터 공유 — 프로토콜은 엔터티가 자신이 제어하는 리소스에 대한 접근 권한을 다른 엔터티에게 부여할 수 있도록 해야 합니다. 다시 말해, 첫 번째 엔터티는 다른 엔터티가 해당 리소스에 대해 일부 작업(읽기, 수정, 제거 등)을 수행하도록 허용할 수 있습니다. 접근 부여는 임시적일 수 있습니다. 즉, 만료 시간이 있을 수도 있고 없을 수도 있습니다. 첫 번째 엔터티는 나중에 만료 시간을 변경하거나 위임을 완전히 취소하여 이러한 위임을 수정할 수 있어야 합니다.

이슈: #27, #118
스토리: 접근 공유, 프로필 공유, 그룹 공유, 건강 기록 접근
인증 메커니즘 — 프로토콜은 중앙화, 연합 및/또는 자기주권 유형의 인증 메커니즘을 지원해야 합니다.

이슈: #25, #90, #115, #128, #39, #49
스토리: 신원 및 자격 증명 관리, 인증 메커니즘
전역적으로 고유한 식별자 — 엔터티와 저장소를 포함한 리소스는 전역적으로 고유하게 식별 가능해야 합니다. 서로 다른 두 리소스가 동일한 식별자를 공유해서는 안 됩니다(다만 하나의 식별자를 가진 “집합적” 리소스가 각각 자체 식별자를 가진 여러 리소스로 구성될 수 있으며, 집합적 리소스에 대해 수행된 작업은 해당 집합적 리소스를 구성하는 모든 리소스에 영향을 줄 수 있습니다). 또한 리소스는 여러 개의 서로 다른 식별자를 통해 식별될 수 있습니다.

이슈: #136, #108
스토리: 전역적으로 고유한 식별자
그룹 기반 접근 제어 — 프로토콜은 컨트롤러가 엔터티의 그룹을 정의하고 관리하며, 그룹 수준에서 접근 제어 규칙을 적용하고, 그룹이 변화함에 따라 권한이 자동으로 갱신되도록 멤버십 변경을 동적으로 전파할 수 있도록 해야 합니다. 또한 프로토콜은 그룹 계층(중첩 그룹으로도 생각할 수 있음)을 허용해야 합니다. 예를 들어 Solid-admin은 Solid-contributors의 하위 집합으로 정의될 수 있으므로 Solid-contributors에 부여된 모든 권한은 Solid-admin에도 적용됩니다.

이슈: #38, #102
스토리: 그룹 공유
제어 위임 — 시스템은 엔터티가 저장소의 제어를 다른 엔터티에게 위임할 수 있도록 해야 합니다. 이러한 위임은 임시적일 수 있습니다. 즉, 만료 날짜 및 시간이 있을 수 있습니다. 또는 영구적일 수도 있습니다. 즉, 만료 날짜가 “없음”이거나 이와 유사한 형태일 수 있습니다. 엔터티는 나중에 만료를 변경하거나 위임을 완전히 취소하는 방식으로 자신의 위임을 수정할 수 있어야 합니다.

스토리: 제어 위임
리소스 변경 구독(알림) — 프로토콜은 리소스 변경 또는 접근 권한 갱신과 같은 중요한 이벤트를 관련 엔터티에게 알리는 메커니즘을 제공해야 합니다. 예를 들어 리소스에 대한 접근 권한이 변경되거나 새 데이터가 제공되는 경우 영향을 받는 당사자에게 적시에 알릴 수 있습니다. 알림 전달은 실시간(예: 푸시/SSE)이거나 큐에 저장된 채널(예: 이메일 또는 inbox)을 통해 이루어질 수 있으며, 사용자 선호와 개인정보 보호를 존중해야 합니다.

이슈: #32, #100, #101
스토리: 권한 변경에 대한 알림, 실시간 알림, 애플리케이션 알림
서버 간 인증 — 프로토콜은 서버 간 및 백엔드 서비스 통합에 적합한 안전한 인증 및 권한 부여 흐름을 지원해야 하며, 신뢰할 수 있는 서비스가 대화형 로그인 없이 사용자 저장소에 접근할 수 있도록 해야 합니다. 가능한 방식으로는 상호 TLS, 서명된 JWT 기반 서비스 자격 증명, 범위가 지정된 장기 토큰 등이 있습니다.

이슈: #40, #92
스토리: 백엔드 서비스 통합
직렬화 형식 — 프로토콜은 저장소의 데이터를 알려진 형식으로 직렬화할 수 있게 해야 합니다.

스토리: 데이터 통합, 개인 정보 관리
저장소의 제어 — 엔터티는 하나 이상의 저장소 제공자 전반에서 하나 이상의 저장소를 제어할 수 있어야 합니다. 저장소는 정확히 하나의 컨트롤러를 가져야 합니다. 이 컨트롤러는 반드시 개인 사람이나 에이전트일 필요는 없으며, 그룹과 같은 추상 엔터티일 수 있습니다.

이슈: #130
스토리: 저장소 소유권
자기 설명적이고 발견 가능한 API — 프로토콜은 서비스가 저장소의 사용 가능한 기능을 발견하고, 데이터 및 접근 제어 인터페이스를 일관되게 탐색할 수 있는 수단을 포함해야 합니다. 이를 통해 서비스는 사용자 관리 저장소 내에서 데이터를 저장, 읽기, 갱신 및 삭제할 수 있으며, 사용자는 데이터와 앱이 생성한 콘텐츠에 대한 소유권과 주권을 유지할 수 있습니다. 이는 응답의 하이퍼미디어 컨트롤 또는 표준 설명자(예: 사용 가능한 작업 또는 엔드포인트를 나타내는 JSON-LD 링크)를 통해 달성될 수 있습니다. 서버는 지원하는 프로토콜 버전, 확장 및 기능에 대한 발견 가능한 설명을 제공해야 합니다.

이슈: #12, #21, #70, #120
스토리: 저장소 설명 및 발견, Bring-Your-Own-Data 앱
서비스 제공자의 사용 — 프로토콜은 엔터티가 일부 기능을 신뢰할 수 있는 서비스 제공자에게 위임할 수 있는 메커니즘을 제공해야 합니다. 일부 상호작용은 서비스 제공자와 엔터티 간의 신뢰 관계를 추가로 요구할 수 있습니다. 이는 엔터티가 그러한 서비스를 운영하거나 자체 호스팅할 수 있는 능력을 방해해서는 안 됩니다. 또한 신뢰 관계는 전이적이지 않다는 점에 유의하십시오. 즉, 엔터티가 서비스 제공자(예: 신원 제공자)를 신뢰한다고 해서, 해당 엔터티가 상호작용하는 다른 서비스 제공자(예: 저장소 제공자)가 그 신원 제공자를 신뢰해야 할 의무는 없습니다.

이슈: #127
스토리: 저장소 제공자를 위한 신뢰 메커니즘
저장소 이식성 — 프로토콜은 엔터티가 저장소의 전체 내용을 한 저장소 제공자에서 다른 저장소 제공자로 포팅, 즉 복사, 이동 또는 전송할 수 있도록 해야 합니다. 이동 또는 전송이 완료되면, 엔터티의 선택에 따라 초기 저장소 제공자는 해당 저장소와 관련된 모든 책임에서 벗어날 수 있습니다.

이슈: #140
스토리: 이식 가능한 저장소
접근 권한 위임 — 전체 저장소 제어 위임을 넘어, 프로토콜은 리소스에 대해 특정 접근 권한을 가진 엔터티가 원 소유자의 허용을 받은 경우 해당 권한의 일부를 다른 엔터티에게 위임할 수 있도록 해야 합니다. 이러한 하위 위임은 임시적이거나 다른 방식으로 범위가 지정될 수 있으며, 원 부여자(또는 리소스 소유자)는 언제든지 원래 권한과 그에 따른 하위 위임 권한을 취소하거나 수정할 수 있어야 합니다.

이슈: #10 [UC] 부서장을 위해 일하는 행정 보조자, #104 [UC] 자율 그룹/조직에 의한 접근 위임
스토리: 행정 보조자, 건강 기록 접근
검색 및 쿼리 — 쿼리 요구사항 모음:

스토리: 검색 기능, 페이지 매김 및 필터링, SPARQL 쿼리
1. pod 수준 쿼리 — ACL을 존중하면서 잠재적으로 큰 pod에서 항목을 쉽게 찾기 위한 SPARQL 쿼리
```
GET <my-pod-path>/__SPARQL?query=SELECT…
Host: <my-pod-server>
```
이슈: #45 SPARQL 쿼리, #152 쿼리(/search)
스토리: 검색 기능, SPARQL 쿼리
1. 메타데이터 쿼리 — ACL을 존중하면서 서버가 유지 관리하는 데이터에 대해 수행하는 SPARQL 쿼리
예: 루트 컨테이너에서:
```
GET <my-pod-path>?query=SELECT…
Host: <my-pod-server>
```
예: 리소스(또는 중첩 컨테이너)에서
```
GET <my-pod-path>/<my-resource>?query=SELECT…
Host: <my-pod-server>
```
1. 리소스 수준 쿼리 — ACL을 존중하면서 다른 사람의 pod를 쿼리
```
GET <my-pod-path>/<my-resource>?query=SELECT…
Host: <my-pod-server>
```
1. 다른 pod 쿼리 — ACL을 존중하면서 다른 사람의 pod를 쿼리
```
GET <other-pod-path>/__SPARQL?query=SELECT…
Host: <my-pod-server>
```
1. 페이지 매김, 필터링, 정렬 — 대규모 결과 집합을 처리하기 위해, 프로토콜은 쿼리 결과의 페이지 매김, 필터링 및 정렬과 같은 기능을 제공해야 하며, 데이터에 대한 고급 시맨틱 쿼리를 위해 표준 쿼리 언어(예: SPARQL)를 지원할 수 있습니다.
이는 프로토콜 수준 쿼리에도 동일하게 적용될 수 있습니다. 예: LWP 컨테이너에 대한 GET

이슈: #103 페이지 매김, 필터링 및 정렬 스토리: 검색 기능, 페이지 매김 및 필터링, SPARQL 쿼리
1. 연합 쿼리 — ACL을 존중하면서 잠재적으로 큰 pod에서 항목을 쉽게 찾기 위해 외부 데이터를 조인하는 SPARQL 쿼리
  1. 여러 pod 간 조인 — ACL을 존중하면서 pod를 조인하는 SPARQL 쿼리
```
GET <my-resource>?query=SELECT…FROM <other-pod-path>…
Host: <my-pod-server>
```
  이슈: #88 리소스 집계
  스토리: 데이터 통합, SPARQL 쿼리
  1. 여러 리소스 간 조인 — ACL을 존중하면서 외부 데이터를 조인하는 SPARQL 쿼리
```
GET <my-resource>?query=SELECT…FROM <wikidata>…
Host: <my-pod-server>
```
```
GET <my-resource>?query=SELECT…SERVICE <wikidata>…
Host: <my-pod-server>
```
프로필 관리 — 프로토콜은 엔터티가 여러 개의 구별된 프로필(예: “work” vs. “personal”)을 가질 수 있도록 지원해야 하며, 각 프로필은 자체 식별자, 메타데이터 네임스페이스 및 접근 제어 규칙을 가져야 합니다. 그렇게 함으로써 데이터가 서로 다른 페르소나 아래에서 선택적으로 공유될 수 있습니다.

스토리: 프로필 공유
접근 요청 처리 — 프로토콜은 엔터티가 현재 접근 권한이 없는 리소스에 대한 접근을 쉽게 요청할 수 있게 하고, 리소스 소유자(또는 컨트롤러)가 그러한 요청을 쉽게 검토하고 승인하거나 거부할 수 있게 해야 합니다. 요청자가 접근을 원한다는 신호를 보내고, 소유자가 알림을 받고 응답할 수 있는 표준 방식이 있어야 합니다. 이는 데이터 소유자가 광범위한 접근을 사전에 부여하지 않고도 요청 시 특정 데이터를 쉽게 공유할 수 있도록 보장합니다.

이슈: #11, #28, #78, #79, #92
스토리: 건강 기록 접근
동의 기반 데이터 공유 —
- 프로토콜은 사용자가 누구와 공유하는지, 무엇을 공유하는지, 공유 목적 및 공유 기간에 대한 세부사항을 포함하여 데이터 공유에 대한 사용자 동의를 기록하고 존중하는 수단을 제공해야 합니다.
- 사용자 동의에 대한 검증 가능하고 감사 가능한 기록(예: 영수증 또는 토큰)이 있어야 하며, 이는 철회 가능하여 동의 철회 시 접근 제거를 보장해야 합니다.
이슈: #141, #81
스토리: 동의 기반 공유
데이터 무결성 검증 — 프로토콜은 저장된 데이터의 무결성을 보장하고 검증하기 위한 메커니즘을 포함해야 합니다. 권한이 부여된 엔터티는 데이터가 변조되었거나 손상되었는지(저장 중이든 전송 중이든)를 감지할 수 SHOULD 있습니다. 예를 들어, 시스템은 클라이언트가 저장소에서 검색한 리소스가 소유자가 원래 저장한 것과 정확히 동일한지 확인할 수 있도록 암호화 해시, 서명 및/또는 체크섬을 사용할 수 있습니다.

이슈:
스토리: 법적 보고
맥락적 접근 제어 — 접근 제어 메커니즘은 맥락 인식 정책을 지원해야 합니다. 엔터티는 시간 창, 위치, 그룹 멤버십 상태 등과 같은 맥락을 기반으로 리소스 접근에 추가 조건을 부과할 수 SHOULD 있습니다. 예를 들어 정책은 특정 시간 동안에만 접근을 허용하거나, 요청 당사자가 해당 시점에 특정 역할 또는 그룹 내에 있는 경우에만 접근을 허용할 수 있습니다.

이슈: #17, #65, #179
스토리: 맥락 인식 접근 정책
신뢰할 수 있는 신원 제공자 — 프로토콜은 저장소 제공자가 어떤 신원 출처든 무조건 수락하는 것이 아니라 자신이 선택한 신원 제공자와 신뢰 관계를 설정할 수 있도록 해야 합니다(다만 이러한 무조건 수락도 구성 가능한 옵션이어야 SHOULD 합니다). 신뢰는 전이적이지 않습니다. 저장소는 신뢰 관계를 상속하지 않으며, 자신이 신뢰하도록 구성된 IdP(일반 소비를 의도한 웹사이트 콘텐츠의 경우 와일드카드일 수도 있고 이를 포함할 수도 있음)로부터의 자격 증명만 수락합니다.

이슈: #129
스토리: 저장소 제공자를 위한 신뢰 메커니즘
제어 이전 — 프로토콜은 엔터티가 저장소의 제어를 다른 엔터티에게 이전, 즉 취소 불가능하게 재할당할 수 있도록 해야 합니다.

스토리: 제어 위임
재개 가능한 대용량 데이터 전송 — 프로토콜은 중단된 업로드/다운로드를 재개할 수 있는 기능을 포함하여 대용량 파일과 데이터 스트림을 효율적으로 처리할 수 있도록 지원해야 합니다. 이는 네트워크 또는 서버 중단이 전체 전송을 처음부터 다시 시작하도록 만들지 않게 하여, 대용량 파일 작업의 신뢰성을 향상시킵니다. 쿼리로 생성된 데이터셋에 대한 재개 지원은 대용량 로컬 저장소를 필요로 할 수 있으며, 이는 모든 배포에서 재개가 지원되지 않을 수도 있음을 의미할 수 있습니다.

이슈: #18
스토리: 대용량 파일 업로드
확장 가능한 저장소 관리 — 프로토콜은 여러 저장소 단위 또는 제공자 전반에서 엔터티의 데이터를 유연하게 관리할 수 있도록 허용해야 하며, 서로 다른 백엔드를 논리적으로 통합할 수 있어야 합니다. 클라이언트는 데이터가 제공자 간에 분할되거나 이전되더라도 하나의 일관된 저장소 보기를 경험할 수 있어야 하며, 관할권 분할 또는 제공자 장애 조치와 같은 시나리오를 지원해야 합니다.

이슈: #110, #136
스토리: 저장소 유연성
뷰 기반 데이터 공유 — 프로토콜은 컨트롤러가 리소스의 파생 “뷰”(예: 필터링, 집계 또는 수정된 하위 집합)를 정의하고 노출할 수 있도록 해야 하며, 수신자가 기본 데이터를 중복하지 않고 권한이 부여된 부분만 볼 수 있도록 해야 합니다.

이슈: #63, #106, #116
스토리: 센서 데이터 공유
기반 프로토콜의 느슨한 결합 — 핵심 데이터 접근 및 신원 상호작용은 단일 전송 또는 인코딩과 분리되어 추상적으로 정의되어야 합니다. HTTP(S)가 예상되지만, 프로토콜의 의미론은 기본 모델을 변경하지 않고 대체 또는 미래 전송(예: gRPC, WebSocket을 통한 GraphQL, 로컬 IPC)에 매핑될 수 있어야 합니다.

이슈: #24
스토리: API 프로토콜 분리
종단 간 암호화 — 프로토콜은 저장되거나 전송되는 데이터가 권한이 있는 당사자 이외의 누구에게도 읽히지 않도록 종단 간 암호화를 가능하게 해야 합니다. 저장소 제공자나 네트워크 중개자도 콘텐츠를 복호화할 수 없습니다(데이터 소유자와 의도된 수신자만 가능). 종단 간 암호화는 표준 알고리즘을 사용하여 저장 중인 데이터와 전송 중인 데이터에 대해 달성 가능해야 합니다.

이슈: #4, #44
스토리: 종단 간 암호화
성능 및 확장성 — 프로토콜과 그 구현은 대규모에서도 높은 성능을 내도록 설계되어야 합니다. 접근 제어 확인과 데이터 작업은 최소한의 오버헤드를 발생시켜야 하며, 설계는 일반적인 웹 성능 요구를 충족하기 위해 배치 처리, 캐싱 및 분산/클러스터 배포를 허용해야 합니다.

이슈: #72
스토리: 고성능 접근 제어
연합 데이터 쿼리 — 프로토콜은 클라이언트가 여러 저장소에 걸쳐 쿼리(연합 SPARQL 포함)를 수행하고, 각 저장소의 접근 제어를 유지하면서 결과를 투명하게 집계하고 반환할 수 있도록 지원해야 합니다.

이슈: #88
스토리: 데이터 통합, SPARQL 쿼리
리소스 버전 관리 — 프로토콜은 리소스의 이전 버전을 유지하고 검색하는 것을 지원해야 합니다. 권한이 부여된 엔터티는 수정 감사 및 변경 되돌리기를 가능하게 하기 위해 데이터의 이전 버전(메타데이터와 접근 제어 상태 포함)을 복구하거나 검사할 수 있어야 하며, 이는 실수로 인한 삭제로부터의 복구도 포함합니다. 이는 시간이 지나도 데이터 내구성과 추적 가능성을 보장하는 데 도움이 됩니다.

스토리: 범용 저장소
Inbox (알림) — 프로토콜은 사용자(또는 그 에이전트/애플리케이션)가 표준화된 방식으로 자신의 저장소를 통해 직접 메시지나 데이터를 교환할 수 있는 메커니즘을 제공해야 하며, 외부 메시징 서비스에 의존하지 않는 내장형 협업을 가능하게 해야 합니다. 예를 들어 사용자는 적절한 권한 부여와 함께 다른 사용자의 저장소로 메시지, 알림 또는 초대를 보낼 수 있어야 하며, 수신 사용자의 클라이언트는 이 메시지를 검색하거나 알림을 받을 수 있습니다.

이슈: #22, #99
스토리: 범용 커뮤니케이션
개인 데이터 프로젝션 — 프로토콜은 기본 리소스를 중복하지 않고, 비-LWS 애플리케이션이 소비할 수 있는 형식(예: JSON, vCard)으로 개인 데이터를 자동 변환(프로젝션)하는 메커니즘을 지원해야 합니다. 이를 통해 데이터 사일로를 방지하고 기존 웹 표준과의 호환성 및 상호운용성을 제공할 수 있습니다. (이는 LWS 애플리케이션 간 상호운용성을 위해 하나의 LWS 데이터 스키마 또는 구조에서 다른 것으로 변환하는 데도 적용될 수 있습니다.)

이슈: #2
스토리: 개인 정보 관리
감사 가능한 추적 — 프로토콜은 권한이 부여된 엔터티가 리소스에 대한 모든 접근 요청 및 부여, 그리고 리소스의 모든 읽기/쓰기/삭제에 대한 감사 가능한 로그에 접근할 수 있게 해야 합니다. 이 로그에는 리소스(예: 디지털 상품)가 생성, 수정, 전달 또는 접근될 때의 검증 가능한 영수증 또는 확인이 포함되어야 하며, 게시자가 성공적인 전달 또는 소비를 확인할 수 있도록 보장해야 합니다.

이슈: #84, #85 스토리: 행정 보조자, 법적 보고, 건강 기록 접근, 디지털 상품 전달
오프라인 접근 및 동기화 — 프로토콜은 엔터티가 네트워크에서 연결이 끊긴 상태에서도 데이터에 접근하고 수정할 수 있도록 해야 하며, 연결성이 복원되면 로컬 변경 사항이 온라인 저장소에 동기화되도록 해야 합니다. 여기에는 오프라인 편집 후 데이터 일관성을 보장하기 위해 데이터 손상에 대한 강력한 보장과 견고한 충돌 해결을 제공하는 것이 포함됩니다.

스토리: 오프라인 데이터 접근, 저장소 감시
자기 설명적 웹사이트 게시 — 프로토콜은 저장소에서 직접 영구 URI를 가진 자기 설명적 웹사이트를 게시하는 것을 지원해야 하며, 지속 가능하고 상호운용 가능한 콘텐츠 호스팅을 가능하게 해야 합니다.

이슈: #31
스토리: 웹사이트 생성
협업 편집 — 프로토콜은 여러 엔터티가 동일한 리소스를 동시에 공동 작성하거나 편집할 수 있도록 하는 선택적 메커니즘(예: 잠금, 낙관적 동시성, CRDT 기반 병합)을 정의해야 하며, 내장된 충돌 감지와 해결을 제공해야 합니다.

이슈: #146
스토리: 시맨틱 협업
시계열 데이터 지원 — 프로토콜은 IoT 스트림 또는 메트릭과 같은 데이터에 대해 구성 가능한 해상도 제한과 다차원 분석을 지원하면서, 시계열 리소스를 저장, 쿼리 및 집계하기 위한 기본 요소를 포함해야 합니다.

이슈: #6
스토리: 시계열 저장소
법적 근거 시행 — 프로토콜은 접근 제어 결정을 법적 근거 또는 정책과 연관시키는 것을 지원해야 합니다. 예를 들어, 구현자는 데이터 접근 규칙에 특정 법적 근거(예: “Consent – GDPR Article 6(1)(a)” 또는 “Contract – GDPR Article 6(1)(b)”)를 태그하고, 이를 감사 추적과 함께 메타데이터로 기록할 수 있어야 합니다.

이슈: #80, #77
스토리: 법적 근거 지원
프로필 상호작용 UI — 프로토콜은 클라이언트가 엔터티의 프로필(예: WebID)을 가져와 표시하고, 지원되는 작업(팔로우, 메시지, 공유)을 함께 보여주는 표준 방법을 정의해야 하며, 사용자가 연락처와 원활하게 상호작용할 수 있도록 해야 합니다.

이슈: #47, #48
스토리: WebID 프로필 상호작용

Linked Web Storage 사용 사례

초록

이 문서의 상태

1. 소개

2. 용어집

3. 사용 사례

3.1 기능적 스토리

3.1.1 데이터 관리

3.1.3 협업 및 커뮤니케이션

3.1.4 애플리케이션 통합

3.1.5 고급 기능

3.2 비기능적 스토리

3.2.1 보안 및 개인정보 보호

3.2.2 성능 및 사용성

3.3 기술적 스토리

3.3.1 신원 인증 및 신뢰

3.3.2 API 및 프로토콜 유연성

3.3.3 저장소 및 리소스 관리

4. 요구사항

Linked Web Storage 사용 사례

초록

이 문서의 상태

1. 소개

2. 용어집

3. 사용 사례

3.1 기능적 스토리

3.1.1 데이터 관리

3.1.2 접근 제어 및 공유

3.1.3 협업 및 커뮤니케이션

3.1.4 애플리케이션 통합

3.1.5 고급 기능

3.2 비기능적 스토리

3.2.1 보안 및 개인정보 보호

3.2.2 성능 및 사용성

3.3 기술적 스토리

3.3.1 신원 인증 및 신뢰

3.3.2 API 및 프로토콜 유연성

3.3.3 저장소 및 리소스 관리

4. 요구사항