Consideration: Create a generic "Collection" class

[siuc-nate]

Since it has come up in relation to the OSN work, we should have an issue to keep track of our thoughts on the matter.

The proposal is not yet formal, but rather, to consider the idea of a generic "Collection" class in CTDL that would in essence be a flat list of resources of whatever combination of types. For instance, a class with properties like:

• name
• description
• subjectWebpage
• CTID
• targetCredential
• targetAssessment
• targetLearningOpportunity
• targetOrganization (or perhaps targetAgent?) (new)
• targetPathway
• targetCompetency
• targetCompetencyFramework
• targetNode (generic URIs)
  etc.

Such a class could theoretically even completely replace the ceterms:PathwaySet class.

[philbarker]

Are the targetXYZ properties meant to indicate members of the collection? If so it seems like a stretch to for a property originally indicating an alignment (or intended alignment, like an aim).
Given the generic nature of the concept, is it necessary to have different properties depending on what the member is?
I would start with member as single property for linking to members of the collection.

[siuc-nate]

Our current usage (and the definition) of ceterms:sourceData most closely matches the idea of a generic property to point to some kind of structured data, so it would be a good fit.

This is also what we selected for the proposed ETPLResource class as a means of pointing to some type of structured data.

[philbarker]

@siuc-nate Good fit with what?

[siuc-nate]

A good fit to use instead of the list of "target" properties.

e.g.:

• name
• description
• subjectWebpage
• CTID
• sourceData

[philbarker]

sourceData could point to structured data about the collection, e.g. to the original OSN representation of the collection. I didn't realize that was what you intended for the target properties.

[philbarker]

For comaprison: schema:Collection "A collection of items e.g. creative works or products." The examples show hasPart is used to point to members of the collection.

[stuartasutton]

While this needs more thought and discussion, I agree with Phil. A property identifying membership in a collection is semantically different beast from the targetxyz properties you list. This need aligns closely with the skos:Collection, skos:OrderedCollection classes and the skos:member property for referencing collection member entities except for its limiting of the range of the skos:member property to concepts.

[siuc-nate]

True. I could see using hasPart for this.