Credential Approval Lists Domain Model and Terms Proposal

[jeannekitchens]

This is to intiate the CAL Terms Proposal.

[siuc-nate]

Two options. Both examples show the use of a Credential bnode to "append" data to a real record, which is a separate use case, but is useful to illustrate.

---

First, the one we discussed last week involving the use of a single generic Member class. The purpose of the Member class is to enable indicating the startDate and endDate for each item on the list (meaning the date the item is added to the list, and the date that item comes off the list). https://github.com/CredentialEngine/Schema-Development/blob/master/Credential%20Approval%20Lists/ProPath%20via%20Member%20Class.json Visually, this can be boiled down to this (boxes with dashed lines are bnodes):

Pros:

• Each item can be independently assigned a startDate and endDate

Cons:

• Each item must be represented via a Member object unless startDate and endDate don't need to be captured

---

Second, one that I am floating as a means of reducing the total number of entities required if it is true that most state CALs will be updated in batches (ie lots of credentials will have the same startDate/endDate). This has the danger that if each item does have a distinct startDate/endDate, you will end up with a lot of single-item Collections. https://github.com/CredentialEngine/Schema-Development/blob/master/Credential%20Approval%20Lists/ProPath%20via%20Collection%20with%20Date%20Range.json Visually:

Pros:

• Useful when lots of items have the same startDate/endDate

Cons:

• Creates a big problem if each item needs to have a distinct startDate/endDate (you will have lots of Collections with just one item)

---

It would be possible/valid to do both, I guess, so that we have a generic Member class for cases where each item needs its own startDate/endDate but could otherwise take advantage of sub-Collections for groups. But if we don't need to have a Member class, we shouldn't create one. This should be driven by the real data. What does the actual data (in particular, ETPLs for various states) look like?

[philbarker]

[with the usual grumbling about bnodes] I would be happy with either of the approaches Nate suggests, though as he points out option 1 is more robust. I don't think either requires duplicating data already in the registry, in option 1 data about the resources can be obtained from the registry via either the proxyFor or sameAs links.

[stuartasutton]

I concur with Phil in terms of option 1. BUT, I do not think that the Members should be bNodes since the Credentials etc. need to be able to reference the member nodes (hasProxy or hasETPLproxy).

[jeannekitchens]

We have to discuss and we have to agree to discuss this in a way that begins with the members of a collection for a list are not bnodes. The members of a list are not just repeating for example a credential as described by a credentialing organizations. The Proxy classes are for describing, for example, a credential in the context of the list irrespective of what the credential organizations publishes. The credential organization may not even be aware their credential is on a list.

@siuc-nate thanks for the JSON examples but it would be more helpful if they were realistic. Using ProPath. Every single list member of an ETPL has a unique start and end date unless they just happened to be approved on thes same day. On the other hand, there can be lists that all get approved on the same day and end on the same day...e,g,, an annual list of quality credentials.

[siuc-nate]

I do not think that the Members should be bNodes since the Credentials etc. need to be able to reference the member nodes (hasProxy or hasETPLproxy).

At the RDF level, those would still be the real classes, so that modeling (something -[hasProxy]-> Credential) would still work. And if a given implementation needed to retain the hasProxy data, they could make those entities directly addressable/accessible. For the registry implementation, I don't think we need that (the proxyFor property going the other way should suffice), so this solution should still work.

the members of a collection for a list are not bnodes

I believe this is a separate issue: the need for one or more entities to be able to contribute data about a resource that they do not have publishing permission for. That problem has a broader scope than Credential Approval Lists, so whatever solution we come up with there is what would be utilized here. Currently, that solution is via bnodes. If a more ideal solution arises, we would use it instead. For example, if we came up with some kind of a "composite credential" or "wiki credential" or even decided to allow any state to publish anything about anything - whatever the solution may be, it would be used here. So for now we can stick with bnodes (as that is what we use with transfer value, which would also be affected by such a TBD solution) knowing that that may change once we solve the broader problem.

thanks for the JSON examples but it would be more helpful if they were realistic. Using ProPath. Every single list member of an ETPL has a unique start and end date unless they just happened to be approved on thes same day.

The examples are reflective of what the real JSON would be. That constraint (everything having its own date range) would fall under the first example, which uses the Member class. I did use the real propath data as part of constructing those examples.

[siuc-nate]

With regard to the ProPath data, there are two ways to look at it:

Current State: Currently, Illinois publishes all of the data. Because of this, the records in the registry published by Illinois have CTIDs and can thus, for our purposes, be considered authoritative records (as in "trusted third party publisher" style). That means that there don't need to be any intermediary Credential bnodes because Illinois can simply provide everything it wants to say in the "real" records.

---

Future State: Where Illinois wants to go is to have the "real" records be published by the "real" authoritative sources - the education/training institutions themselves, rather than having Illinois publish on their behalf. In this case, if the records don't provide everything Illinois wants to say, then (and only then) does Illinois need to provide some source for the information (whether that's a bnode, wiki credential, RDF Star, whatever solution we come up with - that is a separate issue) that can be, in some sense, appended to the "real"/authoritative record.

---

Regardless of what approach solves the problem of "how do multiple sources say things about the same credential", the Collection/Member approach is the same.

[philbarker]

Let me try to summarise some points from yesterdays call, to check that we all took on board the same points

1. proxies are necessary where there is something that needs to be said about a member of a collection that is only true in the context of that specific collection (e.g. the date of its membership of that collection, something about its status in that collection). 1.1 proxies are by definition not the same thing as the resource for which they are a proxy

2. a CAL creator may wish to say things about the resources being listed without adding it to the "main" information about the resource in the registry, e.g. provide a modified description, add information that is not present, suppress irrellevant/distracting information such as a other places a course is offered. 2.1 this information may add-to or over-write information the registry already holds 2.2 this information may be needed for many lists

Looking at the options:

@siuc-nate if I am right about point 2.2 I think that it means bnodes won't work. I think that is Jeanne's point of objection.

Combining the information about the resource into the proxies (as in Jeanne's diagram) doesn't work if there is any information about the member that is only true in the context of that specific collection/CAL -- proxies by purpose only exist only in the context of a single list and so they cannot be the the solution to point 2.2.

In the long term a solution around named graphs could be built, but in the timescale of dealling with CALs we probably need some ad hoc solution based on providing supplementary information about a resource and an indication that that information is not for general consumption.

We could create new classes that are for additonal data only -- that's potentially a lot of new classes, though there might be a way of creating "shadow" data classes with URI based on a different stem but the same name as the RDF classes. I don't much like this idea, it seems like just having a database of JSON objects -- or worse, a mixed RDF / JSON object database.

We could try to come up with something that works as linked data (i.e. RDF) and uses existing classes and has (a) an indication that it is not to be exposed as a description of a credential except for certain CALs; and (b) a link to the resource about which it provides additonal information.

That final option would look a lot like Nate's suggestion, but not bnodes and with an additional property. It would require coding additional logic in order to display the right information for CALs and for the resources outwith CALs.

[siuc-nate]

proxies are necessary where there is something that needs to be said about a member of a collection that is only true in the context of that specific collection (e.g. the date of its membership of that collection, something about its status in that collection).

I would be cautious with the terms since we've already assigned meaning (perhaps different meanings to each of us) to words like "proxy" in the context of this situation. I would refer to it most generically as "some mechanism" for doing what you said.

proxies are by definition not the same thing as the resource for which they are a proxy

Yes, but they may (or may not, depending on the solution?) be of the same @type

a CAL creator may wish to say things about the resources being listed without adding it to the "main" information about the resource in the registry, e.g. provide a modified description, add information that is not present, suppress irrellevant/distracting information such as a other places a course is offered.

I don't see this as really being different from the first point in the sense that "the main record doesn't say what I want it to say, let me fix it"

this information may add-to or over-write information the registry already holds

Adding data is the obvious case, but where/when did overwriting/removing information come up? Is that something we actually need?

this information may be needed for many lists

I was under the impression that the information was contextualized to each list, so it would be different for each list, not spread across multiple lists.

if I am right about point 2.2 I think that it means bnodes won't work.

If we came up with the equivalent of a bnode that wasn't blank (ie it had a URI), then it would work. However, I'm still fairly certain that the additional information is unique to each list (or for the rare cases where it isn't, could simply be recreated for each list, much like we do with classes like PostalAddress/Place)

Regarding your options: In this situation, I think we're moreso dealing with records than with semantic "things", so an approach that can work in that mindset seems like a good one to me. I am still on board with a bnode or bnode-equivalent approach here as I think it is the simplest and most efficient way to solve the problem, and offers the most flexibility if/when a better approach arises to handle the more broadly-scoped problem of "how do two or more entities say things about the same thing without competing for who gets to be "authoritative/real" source of the data?".

That's also why I think we need to keep the Member class, which has a very simple and specific purpose, separate from this solution (no mashup CredentialMemberProxy classes), so we can decouple this solution later and replace it with whatever fancy new one we invent down the road without breaking all of our ETPL Collections.

As I mentioned late into the call, if having a bnode potentially sit between the Member and the "real" thing is the problem, then hang the bnode off of some other property (perhaps this is where a property akin to sourceData comes into play, since we want to provide structured data about something without claiming that the bnode IS the something - that is, we want to provide a record of that something).

If we do in fact need both the idea of "appending data" and "replacing data", that can be likewise accommodated:

For what it's worth, I think the original approach from last week ((Member)-[proxyFor]->(bnode?)-[sameAs?]->(RealThing)) is more ideal since it also accommodates the use case where there is no "real record" to point to, in which case the semantics of "proxyFor" make plenty of sense pointing to a bnode.

[siuc-nate]

I guess I'm mostly struggling to understand @jeannekitchens's aversion to bnodes that brought on all of yesterday's conversation. Specifically, what do they fail to accomplish that you are trying to accomplish? Is it a technical problem? The semantics of it work just fine.

[stuartasutton]

@siuc-nate, as an RDF based approach, the initial assumption should be that everything is identified by URI (i.e., not a bNode) unless there are sound reason for them to be a bNode. We seem to always get it backwards starting with the assumption everything is represented by a bNode and assigned a URI only when a good case is made for doing so. Please note that I managed those two sentences without ever uttering CTID. So, my question is: What's the strong RDF modeling case for these to be bNodes?

[stuartasutton]

Doesn't hasReplacementData actually mean that the member data for a specific attribute in a collection contradicts the source. It isn't "replacing" anything.

[siuc-nate]

We seem to always get it backwards starting with the assumption everything is represented by a bNode and assigned a URI only when a good case is made for doing so.

This is a by-product of our entire infrastructure being CTID-based. In essence, we don't assign URIs unless we need to because assigning URIs is synonymous with assigning CTIDs because of how all of our stuff functions. Is this (and possibly other things) a problem that might be solved if we had a good way to supply URIs to any (reasonable) entity that were GUID-based instead of CTID-based? That would obviously have a lot of implications beyond the scope of this issue but is that something we need to look at in earnest?

What's the strong RDF modeling case for these to be bNodes?

Primarily that they are supplying extra data ranging from a single property to a full-fledged record (for lack of a better term) about the entity that may or may not exist in the registry. Deliberately highlighting their nature as non-primary records seems like what we want to do, even if that data is coming from a state. In other words, they specifically are not "the thing", they are "data about the thing" - hence not having a CTID.

I am less concerned about them being or not being bnodes - my main concern is that we do not invent new doppelganger classes purely to avoid having bnodes. We need to use the existing classes that we already have regardless of whether instances of those classes have a URI (CTID-based or otherwise). I am only focused on bnodes because, as I said, our infrastructure limits our capacity for URIs to things that have CTIDs so we don't have a choice unless we want to look at much deeper technical changes to our systems.

Doesn't hasReplacementData actually mean that the member data for a specific attribute in a collection contradicts the source. It isn't "replacing" anything.

I'm not quite sure what you mean. The intent there was to handle the use case (that I am not certain of the origin/purpose of) that Phil mentioned about needing to provide data that should be interpreted as replacing other data in the main record. In other words, if the record in the registry lists 50 locations, the bnode on the other end of "hasReplacementData" lists just 3, and the consumer of the data should interpret that as "ignore what the main record says for this property and just look at these 3 locations". If that's something we need to be able to do, then that is one way to do it.

[siuc-nate]

I still believe we have two separate use cases:

• Cases where there is a "real record" and some mechanism just exists to alter data for it (e.g., the state just needs to assert a few properties)
• Cases where there is no "real record" and some separate mechanism exists to supply a larger set of what would otherwise be the data in the "real record" (e.g., the state needs to publish a relatively complete record because there is no registry record to point to)

The former seems very well-suited to being a bnode as we discussed last week, though whether such a bnode sits between the Member and the real record or hangs off of some other property of the Member class is something we can discuss here.

The latter seems to be where we have trouble due to the whole CTID/URI/infrastructure/RDF thing. Phil has mentioned that a bnode could be a short-term solution to this, and I agree (admittedly with some bias). I also agree that a longer-term solution should be explored, but that is, again, beyond the scope of this issue. It probably deserves its own github thread.

[philbarker]

Nate, it is important to keep information about the resource's membership of the list separate from the information the resource: your two use cases only cover the information about the resource. For example in:

        {
            "@id": "_:2bbbf9e4-e825-420c-9c53-6d1bcacd8899",
            "@type": "ceterms:Member",
            "ceterms:startDate": "2021-01-01",
            "ceterms:endDate": "2022-01-01",
            "ceterms:proxyFor": "https://sandbox.credentialengineregistry.org/resources/ce-c7b9a991-7a8f-43d6-b865-0b4ad5234f60"
        },

those values for startDate and endDate only apply to one list, and so cannot be merged with data about the resource in any other list or outside of the list. This isn't altering or extending data about the resource as covered in your use cases, because it is not even data about the resource, any more that the name of the owner is data about the resource -- it is data about something else that is related to the resource.

To you previous q about "where/when did overwriting/removing information come up?": I had in mind Jeanne's example of a L.Opp offered at locations in 50 states, but the list author only wanted to show one of those locations, the one in their state.

[siuc-nate]

Yes, the distinction is intentional. The simple Member class covers both of them by pointing to one mechanism or another (or just directly to the "real record" when no such data-altering mechanism is needed).

[jeannekitchens]

@stuartasutton @philbarker @mparsons-ce @siuc-nate based on the CAL Task Group meeting held this week where I went over the model linked in the 1st comment in detail. See slides 8 - 17. , (1) Using Member as a class label is too confusing. I think MemberProfile may address this issue. See updated draft model dated Dec 16th below based on Task group feedback.

[stuartasutton]

Since the word "profile" has no solid meaning in the CTDL context, I have no problem with the change.

[philbarker]

Agreed, though I have wondered whether we might build off schema.org/ListItem https://schema.org/ListItem

Phil

On 17/12/2021 14:39, Stuart Sutton wrote:

Since the word "profile" has no solid meaning in the CTDL context, I have no problem with the change.

— Reply to this email directly, view it on GitHub https://github.com/CredentialEngine/Schema-Development/issues/806#issuecomment-996771952, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAFAU763PTWPR2FGKMJU7NLURNDSLANCNFSM5J6OAAOA. Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.

You are receiving this because you were mentioned.Message ID: @.***>

--

Phil Barker http://people.pjjk.net/phil. http://people.pjjk.net/phil CETIS LLP https://www.cetis.org.uk: a cooperative consultancy for innovation in education technology. PJJK Limited https://www.pjjk.co.uk: technology to enhance learning; information systems for education.

CETIS is a co-operative limited liability partnership, registered in England number OC399090 PJJK Limited is registered in Scotland as a private limited company, number SC569282.

[jeannekitchens]

@philbarker Item Profile would make more sense to this group. An item in a collection and item on a list....makes more sense. Member immediately brings to mind people who join something.

[stuartasutton]

Just to gently push back since we have to live with the solution in many Collection contexts other than this one, please google "member of a collection". "Member" as a property is quite common in the context of collections. Not all collections are lists.

[philbarker]

Good point, well made.

⁣Get TypeApp for Android ​

On 17 Dec 2021, 22:04, at 22:04, Stuart Sutton @.***> wrote:

Just to gently push back since we have to live with the solution in many Collection contexts other than this one, please google "member of a collection". "Member" as a property is quite common in the context of collections. Not all collections are lists.

-- Reply to this email directly or view it on GitHub: https://github.com/CredentialEngine/Schema-Development/issues/806#issuecomment-997057240 You are receiving this because you were mentioned.

Message ID: @.***>

[siuc-nate]

Using Member Profile would imply that the class describes the thing rather than just pointing to it, which we want to avoid. Maybe "CollectionMember" instead?

[siuc-nate]

Also, where did the "reference____" properties in the above diagram originate? You would need one of those properties for every top-level class in CTDL, which we want to avoid. If anything, use ceterms:targetCredential/ceterms:targetAssessment/ceterms:targetLearningOpportunity and so on, but we should stick to our earlier models that used a single property to keep this simple.

[siuc-nate]

Per our 1/7/2022 meeting:

• We want to pursue the approach of allowing "secondary source" records and flagging them as such
• See the last tab of https://credreg.net/page/CredentialApprovalLists for details

Discussion points:

• Define the nature of the Collection Member (or Member Item, or Member Profile, etc) class
• The connection between the Collection Member and the "thing" it is a stand-in for would use ceterms:proxyFor
• Use owl:sameAs to reference a primary source record from a secondary source record
• Determine the best approach for flagging a record as coming from a secondary source (ceterms:fromSecondarySource/ceterms:sdSecondarySource, schema:sdPublisher, a boolean to indicate whether or not something is a primary source record, etc)
  • Consider whether such an approach can also solve the problem of needing to provide a license/rights or other "meta" info
• Discuss the nature of ceterms:membershipCriteria and the use of ceterms:QACredential as its value

Create Collection Member:

URI: ceterms:CollectionMember Label: Collection Member Definition: Resource that identifies a resource that is a member of a collection. Comment: Instances act as proxies or stand-ins for other resources in the context of a particular collection so that the relationships between them and the collection can be stated without implying that those relationships are true in other contexts. Properties: ceterms:name, ceterms:description, ceterms:startDate, ceterms:endDate, ceterms:proxyFor

Create ceterms:hasProxy

URI: ceterms:hasProxy Label: Has Proxy Definition: Indicates a resource that acts as a stand-in for the resource in another context. Domain: ceterms:Credential (and subclasses), ceterms:LearningOpportunityProfile, ceterms:LearningProgram, ceterms:Course, ceterms:AssessmentProfile Range: ceterms:PathwayComponent subclasses, ceterms:CollectionMember

Update ceterms:proxyFor Add:

Subject: ceterms:proxyFor Predicate: schema:domainIncludes Object: ceterms:CollectionMember

Create owl:sameAs

URI: owl:sameAs Label: Same As Definition: TBD Domain: TBD Range: TBD

Create ceterms:listType

URI: ceterms:listType Label: List Type Definition: Type of list, collection, set, or other grouping of resources; select from an existing enumeration of such types. Domain: ceterms:Collection

Create ceterms:ListCategory (Concept Scheme)

URI: ceterms:ListCategory Label: List Category Definition: Types of list, collection, set, or other resource that groups together other resources.

Create Concepts:

URI: listType:ETPL Label: Eligible Training Program List Definition: Approved list of Workforce Innovation and Opportunity Act (WIOA) programs per the promulgating body.

URI: listType:GIBill Label: GI Bill Definition: Approved Learning Opportunities, Learning Programs, Courses and Credentials qualifying for GI Bill per the promulating body.

URI: listType:IndustryRecognized Label: Industry Recognized Definition: Recognized list of Learning Opportunities, Learning Programs, Courses, Assessments or Credentials based on factors such as job market demand per the promulgating body.

URI: listType:Quality Label: Quality Definition: Learning Opportunities, Learning Programs, Courses, Assessments or Credentials that meet criteria for quality as determined by the promulgating body.

URI: listType:Perkins Label: Perkins Definition: Approved list of Perkins programs per the promulating body.

[siuc-nate]

Consider "Collection Type" and "Collection Category" instead of "List Type" and "List Category", since I would think that Collection is more broadly-scoped than List (Collection is a superclass of Competency Framework and Pathway Set, so it encompasses structured things as well). That said, we don't have a strict definition of what a "List" is either, so it may be fine as-is.

[siuc-nate]

Regarding the primary/secondary source implementation, I am leaning in the direction of providing two pieces of data:

• The source of the data (that is, the ultimate owner of the data, ignoring any authorized/trusted third-party publishing)
• A boolean indicating whether or not the record is considered by credential engine to be a "primary source" record

The intent is to future-proof the implementation against future use cases by decoupling the notion of "who published it" from the notion of "is it primary source data?". In terms of how this is implemented, I am of two minds:

On the one hand, we could stick with a purely envelope-based implementation, as @philbarker suggested

• This puts us closer to named graphs
• The envelope already contains the ultimate owner of the data (see the owned_by property)
• The envelope already contains a reference, if applicable, to an authorized/trusted third-party publisher (the published_by property), which helps disambiguate the meaning of owned_by
• It would simply require the addition of a property like from_primary_source or something similar to the envelope
• It would be possible to create a registry API endpoint that returns a more JSON-LD-like version of relevant envelope metadata if that is necessary
• Given that envelopes are directly tied to the way that information is published, looking up the envelope for a CTID would always give you the correct information (which is important for cases where the payload contains a number of top-level items, such as competency frameworks, concept schemes, pathways, likely soon collections, etc)
• This could be integrated into the search API as with search:recordOwnedBy and search:recordPublishedBy
• Adding the boolean property would (along with the existing properties) enable use cases like:
  • Give me only primary source records (search:fromPrimarySource = true)
  • Give me only secondary-source records (search:fromPrimarySource = false)
  • Is this record a primary source record? (retrieve the envelope and check the from_primary_source property)
  • Give me all of the primary source records from [organization X] (search:recordOwnedBy = organization X, search:fromPrimarySource = true)
  • Give me all of the secondary source records from [organization X] (search:recordOwnedBy = organization X, search:fromPrimarySource = false)
  • etc.

On the other hand, we could inject ceterms:sdRecordOwnedBy and ceterms:sdFromPrimarySource into the payload itself:

• The search API would support this natively
• This would guarantee that that information is always delivered as part of the record (which may be important considering how long/how often we've emphasized that all of the data in the registry is from primary sources)
• It opens the door (for better or worse) to other "meta" properties like ceterms:sdLicense
• Such meta terms would need to be injected into top-level entities even when those entities are small and numerous (e.g. each of the competencies for a framework)

That last one could be mitigated by only injecting a single property (something like ceterms:sdMetadata) that links to some object (either the envelope or perhaps some bespoke object that could be delivered in the @graph when the @graph is retrieved) that contains the list of "meta" properties like owner, primary source, license, etc. since those would always be the same for every competency in a framework, every concept in a scheme, etc.

Overall, I lean towards the former approach, as it is the least invasive and is more future proof (in addition to already existing, aside from the from_primary_source boolean). However, I can potentially see justification for the second approach (since it would make it more plainly obvious to a data consumer when a record isn't from a primary source - but then again, some consumers may not care about that as long as the data is accurate). Some kind of hybrid approach (such as injecting a single property into top level classes that links to a JSON-LD representation of data that is actually stored in an envelope) may buy us the best of both worlds and leave more room for future expansion without clouding the payloads.

At the moment, I think we should move forward with an envelope-based approach as described above. If it turns out that that is sufficient, then our job is done; if not, then we can explore injecting data into the payloads.

[siuc-nate]

Remaining points to cover:

• Consider use of Collection Type/Collection Category instead of List Type/List Category
• Consider pros/cons of owl:sameAs, ceterms:sameAs, schema:sameAs, ceasn:exactAlignment, or similar terms
• Determine the definition, domain, and range of owl:sameAs (if we stick with that)
• Discuss the nature of ceterms:membershipCriteria and the use of ceterms:QACredential as its value
• Determine the best handling for "primary source" vs "secondary source" handling as described in my previous post

[siuc-nate]

Updated domain model:

[stuartasutton]

I have a somewhat tagential question, and, again, I am not sure I can articulate it very well. My question stems from whether the distinctions between "primary source" and "secondary source" are generally applicable or whether they are artifacts of how the Registry is implemented. We have had to be on guard since the beginning to not confuse implementation artifacts of the Registry with notions that belong to the generally applicable CTDL (i.e., confusing Registry fringe cases with more general needs). In a way, the circumstance that led to splitting off some Registry needs into the "meta" namespace.

If a property to indicate "primary source" or "secondary source" (as well as my pet peeve of "top-level" entity) is a Registry implementation artifact, it really belong to a separate Credential Registry namespace--currently the "meta" namespace. Such a separate namespace is exactly what we'd suggest to some 3rd party that had implementation-centric needs for a property or two--i.e., define them locally in your own namespace and integrate them into your CTDL application profile schema. In sum, in its relationship to the CTDL, the Registry is a 3rd party that may have peculiar needs of its own that shouldn't clutter the CTDL namespace.

[siuc-nate]

It's more of a CE policy thing, though it's reflected in the Registry data. If we stick with a purely envelope based approach, then I don't think there would be any CTDL changes needed (hence no explicit property in my domain model). If we did decide to create some kind of sd____ property(ies), then I'm fine with putting them in the meta namespace (or wherever makes sense).

[siuc-nate]

Per our 1/11/2022 meeting: Re: Membership Criteria

• Use ceterms:condition instead of ceterms:membershipCriteria (no QA Credential)
• Add ceterms:jurisdiction to ceterms:Collection

Re: Same As

• Use owl:sameAs
• Definition: Links an individual to an individual; such an owl:sameAs statement indicates that two URI references actually refer to the same thing: the individuals have the same "identity".
• https://www.w3.org/TR/owl-ref/#sameAs-def
• Domain and Range: rdfs:Resource

Re: List Type/Collection Type

• Use Collection Type / Collection Category

Re: Secondary source publishing

• Move forward with the envelope-based approach described above

[stuartasutton]

Nate, couldn't we still use membershipCriteria and declare it a subproperty of ceterms:condition? While using ceterms:condition instead of membershipCriteria would not be incorrect, it is certainly less precise.

[jeannekitchens]

@siuc-nate please update the explanatory diagram to correspond to all changes discussed over the past week. It's my understanding that, for example, a conclusion was reached that QA Credential did not belong in the model. Instead, the membershipCriteria property should point to a ConditionProfile where the ceterms:condition property could identify the array of membership criteria statements. With QA Credential out of the model, the jurisdiction property could be placed on Collection pointing to the Jurisdiction Profile.

Include any/all updates not currently reflected here by duplicating the diagram and updating the date. Also, please create a clean proposal with all proposed updates.

https://drive.google.com/file/d/17jM34lLSYTQPX9cSoWHbJduTdWsnR3cu/view?usp=sharing

[siuc-nate]

@stuartasutton It depends on whether it would be a subproperty of ceterms:condition or a new property that points to Condition Profile as @jeannekitchens suggests above. We should probably discuss it since we did spend a fair chunk of time on this one in last week's meeting.

[jeannekitchens]

@siuc-nate please update the diagram and only use a new property if we really need it. Rather than you all rehash what you discussed last week, far more productive to have diagram and proposal to tweak rather than start all over again. Thanks!

[siuc-nate]

Updated diagram: Triple diagram: Cross State Linking of Credentials

Proposal: Create Collection Member:

URI: ceterms:CollectionMember Label: Collection Member Definition: Resource that identifies a resource that is a member of a collection. Comment: Instances act as proxies or stand-ins for other resources in the context of a particular collection so that the relationships between them and the collection can be stated without implying that those relationships are true in other contexts. Properties: ceterms:name, ceterms:description, ceterms:startDate, ceterms:endDate, ceterms:proxyFor

Create ceterms:hasProxy

URI: ceterms:hasProxy Label: Has Proxy Definition: Indicates a resource that acts as a stand-in for the resource in another context. Domain: ceterms:Credential (and subclasses), ceterms:LearningOpportunityProfile, ceterms:LearningProgram, ceterms:Course, ceterms:AssessmentProfile Range: ceterms:PathwayComponent subclasses, ceterms:CollectionMember

Create ceterms:membershipCondition

URI: ceterms:membershipCondition Label: Membership Condition Definition: Conditions and requirements to be included as a member. Domain: ceterms:Collection Range: ceterms:ConditionProfile

Update ceterms:proxyFor Add:

Subject: ceterms:proxyFor Predicate: schema:domainIncludes Object: ceterms:CollectionMember

Create owl:sameAs

URI: owl:sameAs Label: Same As Definition: Links an individual to an individual; such an owl:sameAs statement indicates that two URI references actually refer to the same thing: the individuals have the same "identity". Domain: rdfs:Resource Range: rdfs:Resource

Create ceterms:collectionType

URI: ceterms:collectionType Label: Collection Type Definition: Type of collection, list, array, or other grouping of resources; select from an existing enumeration of such types. Domain: ceterms:Collection

Create ceterms:CollectionCategory (Concept Scheme)

URI: ceterms:CollectionCategory Label: Collection Category Definition: Types of collection, list, array, or other resource that groups together other resources.

Create Concepts:

URI: collectionCategory:ETPL Label: Eligible Training Program List Definition: Training programs meeting Workforce Innovation Opportunity Act requirements per the promulgating body.

URI: collectionCategory:GIBill Label: GI Bill Definition: Education and training programs qualifying for GI Bill per the promulgating body.

URI: collectionCategory:IndustryRecognized Label: Industry Recognized Definition: Learning Opportunities, Learning Programs, Courses, Assessments or Credentials recognized in one or more industries based on factors such as job market demand per the promulgating body.

URI: collectionCategory:Quality Label: Quality Definition: Learning Opportunities, Learning Programs, Courses, Assessments or Credentials that meet criteria for quality as determined by the promulgating body.

URI: collectionCategory:Perkins Label: Perkins Definition: Credentials approved for Perkins Act funding or accountability per the promulgating body.

[jeannekitchens]

@siuc-nate @stuartasutton @philbarker @mparsons-ce

Per a meeting today with Indiana Commission for Higher Education, we need to add at least one more Concept to CollectionCategory. Likely, we need to add a very similar concept for K-12. I added it to the [Google doc version of this proposal (https://docs.google.com/document/d/1e-USiDc4dzj9db0nLTsfiWKmkxGiVRkIWqXaS8zQRCU/edit#))]

URI: collectionCategory:StateApprovedPostsecondaryPrograms Label: State Approved Postsecondary Programs Definition: Learning Opportunities, Learning Programs, Courses, Assessments or Credentials approved by a state agency to be offered within that state’s jurisdiction by postsecondary institutions.

Depending on how this ends up better labeled and defined, create a similar URI/Label/Definition for State Approved K-12 Programs.

I couldn't think of a less verbose label or definition so edits are welcomed. I'm also sending this to Indiana Commission for Higher Education. Also, adding them to techncial team interview list.

[siuc-nate]

It's a little overly-specific, I think. I would suggest broadening it, either to "state approved programs" or just "state approved" so that we don't end up needing terms for state-approved things other than postsecondary programs. There's also the international considerations (e.g. "province-approved programs") and other scopes ("nationally approved programs" or "city approved programs" etc). Maybe just "Government Approved Programs"? But then "approved" has kind of a special meaning in CTDL too, would we also need to consider "accredited" programs and such?

Also, more of a general thought than a reaction to this specifically: Should we explore requiring some kind of threshold of demand/usage for list types before adding them to CTDL? Keep in mind that anyone can publish and use their own list type concepts.

[jeannekitchens]

I asked Ken during our meeting and he confirmed the specificity. All states have a postsecondary approval agency. His list would be approved state agency approved postsecondary programs. Every state has a similar set up for K-12. As we talked about with Indiana today. The state will be publishing their approved program directory and the colleges such as Ivy Tech are expected to publish as well. Where applicable Indiana will link to primary source records.

[stuartasutton]

I'm sort of with Nate on the specificity. Doesn't "StateApproved" and "PostsecondaryPrograms" make this very US-centric. "State Approved" vs "Government or Quasi-Government Approved", "Postsecondary Programs"/"Tertiary Programs". I'd lay bets that these list notions in this general context have applicability in places other than the US.

[siuc-nate]

To be fair, we do already have the notion of "state" in several existing terms:

• StateLocalGrant
• StateLocalLoan
• StateLocalMilitaryAssistance
• StateLocalScholarship
• StateLocalWork
• InState
• OutOfState

However, all of the financial aid terms there use "state, province, region, and/or local government" in their definitions, and the in-state/out-of-state terms use "state or province", so maybe we can still soften up the proposed term a bit.

[jeannekitchens]

Please provide edits to the definition that accomplish the Collection being a state approved postsecondary program list. That's what they'll specifically publish as stated by the person directly overseeing the Indiana agency that is responsible for postsecondary program.approval. Nate and Mike heard him state this. So, every state in the US has a state agency specifically responsibile for postsecondary program approval and they create lists of the state approved postsecondary programs. Many other countries have ministries that approve programs that would be akin to a federal approval here. However. Here postsecondary program approval occurs at the state level.

On Tue, Jan 25, 2022, 3:04 PM Stuart Sutton @.***> wrote:

I'm sort of with Nate on the specificity. Doesn't "StateApproved" and "PostsecondaryPrograms" make this very US-centric. "State Approved" vs "Government or Quasi-Government Approved", "Postsecondary Programs"/"Tertiary Programs". I'd lay bets that these list notions in this general context have applicability in places other than the US.

— Reply to this email directly, view it on GitHub https://github.com/CredentialEngine/Schema-Development/issues/806#issuecomment-1021689927, or unsubscribe https://github.com/notifications/unsubscribe-auth/AE7SXVWSKZLQFFHZDTJJ753UX4T6TANCNFSM5J6OAAOA . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.

You are receiving this because you were mentioned.Message ID: @.***>

[philbarker]

I don't mind this level specificity in the context of a concept scheme, it can be useful to get precisely the right results. If we get several specific terms in the same area we can always add a broader term.

Absent other context, most people outwith the US will read "state" as "national" -- so "state, province, region, and/or local government" will be read to include national government -- and in many countries these are a function of national government (or their agencies). If you need a definition that excludes sovereign state then you could call it an administrative division.

[stuartasutton]

I am less concerned with the label than the definition and I certainly am not questioning whether every U.S. state has one of these; but the definition should be broadened to make sure it is internationally accommodating with text such as "state, province, region, and/or local government". We don't want to exclude "sovereign states" since the U.S. states are, in fact considered sovereign states.

[siuc-nate]

I have attempted to capture, in pending CTDL and the history tracking, all of the changes documented both in this thread and in the planning google doc. There were some differences here and there and some gaps I had to fill in, so it would be good to review these before we close the issue.

[siuc-nate]

Add Comment for CollectionMember per @philbarker: "The data recorded for a Collection Member should refer to the membership of the resource in a Collection."

[siuc-nate]

Also: Include CAL terms in the policy updates and update the concepts per Scott's advisement: https://docs.google.com/document/d/1e-USiDc4dzj9db0nLTsfiWKmkxGiVRkIWqXaS8zQRCU/edit

Also: Add comment/usage note to ETPL concept indicating that it is to be used for collections of programs/courses despite the label/definition referring to providers

[siuc-nate]

Changes made per the above posts: collectionCategory:ETPL

• Updated skos:prefLabel to "Eligible Training Providers List"
• Updated skos:definition to "Training providers meeting the requirements stipulated in the Workforce Innovation and Opportunity Act per the promulgating body."
• Added dct:description: "This list includes the Learning Opportunities and Credentials offered by training providers that have met requirements."
• Updated history tracking to match the above changes

collectionCategory:Perkins

• Updated skos:definition to "Credentials approved for funding under the Strengthening Career and Technical Education for the 21st Century Act (Perkins V) per the promulgating body."
• Updated history tracking to match the above change

ceterms:CollectionMember

• Added vann:usageNote (dct:description was already used): "The data recorded for a Collection Member should refer to the membership of the resource in a Collection."
• Updated history tracking to match the above change

Policy:

• Updated the pending policy for Collection and Collection Member