-
Notifications
You must be signed in to change notification settings - Fork 1
added Meeting object - for review #6
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
base: main
Are you sure you want to change the base?
Conversation
| export * from "./acp/mod.js" | ||
| export * from "./solid/mod.js" | ||
| export * from "./webid/mod.js" | ||
|
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
| export * from "./rdfs.js" | ||
| export * from "./solid.js" | ||
| export * from "./vcard.js" | ||
| export * from "./ical.js" No newline at end of file |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
| export * from "./ical.js" | |
| export * from "./ical.js" | |
| dtstart: "http://www.w3.org/2002/12/cal/ical#dtstart", | ||
| location: "http://www.w3.org/2002/12/cal/ical#location", | ||
| summary: "http://www.w3.org/2002/12/cal/ical#summary", | ||
| vevent: "http://www.w3.org/2002/12/cal/ical#Vevent" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
| vevent: "http://www.w3.org/2002/12/cal/ical#Vevent" | |
| Vevent: "http://www.w3.org/2002/12/cal/ical#Vevent" |
| export * from "./Container.js" | ||
| export * from "./ContainerDataset.js" | ||
| export * from "./Resource.js" | ||
| export * from "./Meeting.js" No newline at end of file |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
| export * from "./Meeting.js" | |
| export * from "./Meeting.js" | |
| export class MeetingDataset extends DatasetWrapper { | ||
| get meeting(): Iterable<Meeting> { | ||
| return this.instancesOf(ICAL.vevent, Meeting) | ||
| } | ||
| } |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This should live in its own file: MeetingDataset.ts.
Also, fix capitalisation (reflects further review comments):
| export class MeetingDataset extends DatasetWrapper { | |
| get meeting(): Iterable<Meeting> { | |
| return this.instancesOf(ICAL.vevent, Meeting) | |
| } | |
| } | |
| export class MeetingDataset extends DatasetWrapper { | |
| get meeting(): Iterable<Meeting> { | |
| return this.instancesOf(ICAL.Vevent, Meeting) | |
| } | |
| } |
It would be interesting to add a link to ical to justify why we use classification based selection (no properties used in the context of this "shape" actually has only domain Vevent: https://www.w3.org/2002/12/cal/ical.n3).
And maybe consider actually using a union pattern with subjectof the various used properties (because in this context, we might only use the properties for Vevents).
Example:
const subjects = new Set([
...this.instancesOf(ACP.AccessControlResource, AccessControlResource),
...this.subjectsOf(ACP.resource, AccessControlResource),
...this.subjectsOf(ACP.accessControl, AccessControlResource),
...this.subjectsOf(ACP.memberAccessControl, AccessControlResource)
])
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Corollary: If tdf:type is the chosen modelling paradigm (and I don't agree that it should be, I would prefer usage based classification) then the mapping class should enable consumers to read/write its type.
See https://github.com/solid/object/blob/main/src/acp/Typed.ts for a pattern for working with type statements.
| <https://example.org/meeting/1> a cal:Vevent ; | ||
| cal:summary "Team Sync" ; | ||
| cal:location "Zoom Room 123" ; | ||
| cal:comment "Discuss project updates" ; | ||
| cal:dtstart "2026-02-09T10:00:00Z"^^xsd:dateTime ; | ||
| cal:dtend "2026-02-09T11:00:00Z"^^xsd:dateTime . |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I know that is what corresponds to the current shape in the pane.
However, could you find a few slightly more comprehensive ical events examples so that we create a class that might be a bit more usable?
I wonder if we can get at least the properties corresponding to the main fields in all well known calendar systems. See maybe RFC5545 section 4 for examples.
| }); | ||
|
|
||
|
|
||
|
|
||
| }); No newline at end of file |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
| }); | |
| }); | |
| }); | |
| }); | |
| import { describe, it } from "node:test" | ||
|
|
||
| import { MeetingDataset } from "@solid/object"; | ||
|
|
||
|
|
||
| describe("MeetingDataset / Meeting tests", () => { | ||
|
|
||
| const sampleRDF = ` |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
| import { describe, it } from "node:test" | |
| import { MeetingDataset } from "@solid/object"; | |
| describe("MeetingDataset / Meeting tests", () => { | |
| const sampleRDF = ` | |
| import { describe, it } from "node:test" | |
| import { MeetingDataset } from "@solid/object"; | |
| describe("MeetingDataset / Meeting tests", () => { | |
| const sampleRDF = ` |
| // Check property types and values | ||
|
|
||
| assert.equal(meeting.summary, "Team Sync"); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
| // Check property types and values | |
| assert.equal(meeting.summary, "Team Sync"); | |
| // Check property types and values | |
| assert.equal(meeting.summary, "Team Sync"); |
| assert.equal(meeting.comment, "Discuss project updates"); | ||
|
|
||
|
|
||
| assert.ok(meeting.startDate instanceof Date); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
| assert.equal(meeting.comment, "Discuss project updates"); | |
| assert.ok(meeting.startDate instanceof Date); | |
| assert.equal(meeting.comment, "Discuss project updates"); | |
| assert.ok(meeting.startDate instanceof Date); |
| }); | ||
|
|
||
|
|
||
|
|
||
| it("should allow setting of meeting properties", () => { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
| }); | |
| it("should allow setting of meeting properties", () => { | |
| }); | |
| it("should allow setting of meeting properties", () => { |
| assert.ok(meeting.endDate instanceof Date, "endDate should be a Date"); | ||
|
|
||
| }); | ||
|
|
||
|
|
||
| it("should ensure all properties are unique text or date values", () => { | ||
|
|
||
| const duplicateRDF = ` |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
| assert.ok(meeting.endDate instanceof Date, "endDate should be a Date"); | |
| }); | |
| it("should ensure all properties are unique text or date values", () => { | |
| const duplicateRDF = ` | |
| assert.ok(meeting.endDate instanceof Date, "endDate should be a Date"); | |
| }); | |
| it("should ensure all properties are unique text or date values", () => { | |
| const duplicateRDF = ` |
| export class MeetingDataset extends DatasetWrapper { | ||
| get meeting(): Iterable<Meeting> { | ||
| return this.instancesOf(ICAL.vevent, Meeting) | ||
| } | ||
| } |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Corollary: If tdf:type is the chosen modelling paradigm (and I don't agree that it should be, I would prefer usage based classification) then the mapping class should enable consumers to read/write its type.
See https://github.com/solid/object/blob/main/src/acp/Typed.ts for a pattern for working with type statements.
| } | ||
|
|
||
| } |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
| } | |
| } | |
| } | |
| } |
| import { ICAL } from "../vocabulary/mod.js" | ||
|
|
||
|
|
||
| export class MeetingDataset extends DatasetWrapper { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
| import { ICAL } from "../vocabulary/mod.js" | |
| export class MeetingDataset extends DatasetWrapper { | |
| import { ICAL } from "../vocabulary/mod.js" | |
| export class MeetingDataset extends DatasetWrapper { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think that it would be worth considering a test pattern for mutations where
- Test has some RDF in Turtle
- RDF is is loaded into a dataset
- Dataset is wrapped by mapping classes
- Instances of wrappers are mutated
- Actual dataset is asserted to be isomorphic with an expected dataset
This is more robust in a way because it does not rely on ther wrappers for reading out values modified by the wrapper itself.
Reference https://github.com/SolidOS/meeting-pane/blob/4a180ebdcbbda2210b0117a058672392fa494079/src/meetingDetailsForm.ttl