Consider how to construct a Support Service hierarchy

[siuc-nate]

Currently we have:

SupportService -[hasSupportService]-> SupportService

Would it make more sense to have:

SupportService -[ceterms:hasPart]-> SupportService
SupportService -[ceterms:isPartOf]-> SupportService

This would mirror how we construct similar relationships and enable for reverse connections (ie child service pointing to parent service) which makes publishing more efficient (since the parent need not be republished every time a child is added/removed)

[philbarker]

I am wary about using hasChild / isChildOfbecause it comes from the ceasn namespace that deals with conceptually different kinds of things to the ctdl namespace. This is reinforced by the comment for hasChild:

This property identifies a child node in the downward path in the chain of resources in a taxon path.

Wouldn't it be better to use hasPart / isPartOf? The definition seems to fit

Indicates a separately identifiable and independently useful component of the entity.

Or alternatively, create an inverse property for hasSupportService

I think the last option is my favoured option. I'm sure we considered using hasPart and hasChild and decided against it because the relationship between services is different to those between other things (they may not be part of the same hierarchy, they may be not be components of the same entity).

[siuc-nate]

I had updated my post shortly after making it to use hasPart/isPartOf, so I agree there.

the relationship between services is different to those between other things (they may not be part of the same hierarchy, they may be not be components of the same entity).

I disagree here, though. What we're trying to express here is specifically the case where one is a part of the other (e.g. some specific SNHU service is a part of SNHU's services). I think that makes at least as much (if not more) sense as a credential being "part of" another credential or a learning opportunity being "part of" another learning opportunity.

That said, we should probably try to figure out best practices with regard to how this kind of thing should be modeled. If an organization can have an array of Support Services, we don't need to rigidly stick to the idea that there must be one single top-level service with more specific ones hanging off of it if simply having the more specific ones in an array at the top level will do.

As part of that, we should determine what kind of scope a Support Service instance should have when it comes to trying to identify and tag the service (i.e., for the sake of searching/filtering/comparing) vs trying to describe the service. I worry we could wind up getting so deep into that that we find ourselves effectively trying to replace the entire SNHU support service website by trying to capture everything - and that isn't what CTDL is for. Support Service is already several steps removed from describing credentials, let's not make it more complex than we absolutely need to make it.

[philbarker]

I think hasPart will work. It's not my preference because "part" is really broad concept. An arm is part of a human; water is part of a human: the difference is clear when you compare the effect removing and arm from the body to removing the water in a body.

Should we care about these different types of part? Maybe. One useful thing to consider in whether characteristics are transitive over relationships. That is does a part inherit any properties from the thing it is part of. The answer depends on what type of part it is (consider skin color for the different type of parts of a body).

I think you are on to something about providing an array rather than trying to make things part of something else. And sure, let's not go deeper than we need to.

[siuc-nate]

I went through the SNHU support site to try to get a sense of how their information is organized and which pages would be relevant to us, in hopes of figuring out what their Support Service data structure should look like. They tend to intermingle support information with non-support information, so it's possible I've missed some things, but here are my findings:

https://docs.google.com/spreadsheets/d/1nyRswaPJGD66-2pPdSeM9Qxu6l1LwG64C4JMrrTUGeI/edit#gid=0

I organized it by groups based on the URL structure (following which pages link to which other pages results in circular paths eventually), then by which pages appeared to have any support-related information on them. From this, I will try to stub out a sensible set of Support Service CTDL data, and use that to explore what kind of partitive structure may make sense.

[siuc-nate]

I have created some JSON-LD based on the data in the spreadsheet linked above: https://github.com/CredentialEngine/Schema-Development/blob/master/SupportServicesTaskGroup/Examples/SNHU-expanded.json

I started with the four categories SNHU prescribed (on-campus, online, military, and international) and dug through the pages based on my previous analysis of which ones actually had support-related data, and came up with a flat list of support services that should cover everything other than the financial assistance stuff (which is mostly found in the military pages and was beyond the scope of what I was trying to accomplish here).

What I wound up with was a listing of:

• Campus Accessibility Services (covers a lot of general stuff)
• Wellness Center (mostly healthcare-related)
• The Wolak Learning Center (mostly peer/tutoring related)
• SNHU Services for Online Students (Not much actual support data here, this was mostly about their online courses. This one could probably be dropped)
• Online Accessibility Center (Not much actual support data here either, but I captured what I could)
• Military Tuition Assistance, Discounts and Benefits (most of the data on the page would belong in Financial Assistance Profile)
• International Student Services (not much actual support data here, most of it was promotional/informational or describes non-support services)

Some of this probably could be put into a hierarchy, but there really isn't a need to do so from what I can tell. I would still lean towards hasPart/isPartOf if we need to do that.

[siuc-nate]

Compare the above to the published data. There are some interesting differences in what's covered, where, and how: https://sandbox.credentialengine.org/finder/SupportService/31/SNHU_Student_Support

[jeannekitchens]

Updated domain model https://drive.google.com/file/d/14wCys2PljwO3NubftGE7-j7pBRD7YamC/view?usp=sharing

[siuc-nate]

I think this was already handled with the original Support Service proposal, specifically via the inclusion of ceterms:hasSupportService as a property of the Support Service class itself.

Do we need to keep this issue open?

[jeannekitchens]

I think it can be closed.

[jeannekitchens]

Closing this issue.