Skip to content

Conversation

@tgra
Copy link
Member

@tgra tgra commented Feb 9, 2026

export * from "./acp/mod.js"
export * from "./solid/mod.js"
export * from "./webid/mod.js"

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

export * from "./rdfs.js"
export * from "./solid.js"
export * from "./vcard.js"
export * from "./ical.js" No newline at end of file
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
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"
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
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
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
export * from "./Meeting.js"
export * from "./Meeting.js"

Comment on lines +5 to +9
export class MeetingDataset extends DatasetWrapper {
get meeting(): Iterable<Meeting> {
return this.instancesOf(ICAL.vevent, Meeting)
}
}
Copy link
Member

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):

Suggested change
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)
        ])

Copy link
Contributor

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.

Comment on lines +14 to +20
<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 .
Copy link
Member

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.

Comment on lines +141 to +145
});



}); No newline at end of file
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
});
});
});
});

Comment on lines +3 to +10
import { describe, it } from "node:test"

import { MeetingDataset } from "@solid/object";


describe("MeetingDataset / Meeting tests", () => {

const sampleRDF = `
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
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 = `

Comment on lines +33 to +35
// Check property types and values

assert.equal(meeting.summary, "Team Sync");
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
// Check property types and values
assert.equal(meeting.summary, "Team Sync");
// Check property types and values
assert.equal(meeting.summary, "Team Sync");

Comment on lines +37 to +40
assert.equal(meeting.comment, "Discuss project updates");


assert.ok(meeting.startDate instanceof Date);
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
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);

Comment on lines +45 to +49
});



it("should allow setting of meeting properties", () => {
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
});
it("should allow setting of meeting properties", () => {
});
it("should allow setting of meeting properties", () => {

Comment on lines +95 to +102
assert.ok(meeting.endDate instanceof Date, "endDate should be a Date");

});


it("should ensure all properties are unique text or date values", () => {

const duplicateRDF = `
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
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 = `

Comment on lines +5 to +9
export class MeetingDataset extends DatasetWrapper {
get meeting(): Iterable<Meeting> {
return this.instancesOf(ICAL.vevent, Meeting)
}
}
Copy link
Contributor

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.

Comment on lines +50 to +52
}

}
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
}
}
}
}

Comment on lines +2 to +5
import { ICAL } from "../vocabulary/mod.js"


export class MeetingDataset extends DatasetWrapper {
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
import { ICAL } from "../vocabulary/mod.js"
export class MeetingDataset extends DatasetWrapper {
import { ICAL } from "../vocabulary/mod.js"
export class MeetingDataset extends DatasetWrapper {

Copy link
Contributor

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

  1. Test has some RDF in Turtle
  2. RDF is is loaded into a dataset
  3. Dataset is wrapped by mapping classes
  4. Instances of wrappers are mutated
  5. 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.

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

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants