Skip to content
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

Add ceterms:industryType and ceterms:occupationType to ceasn:CompetencyFramework #557

Closed
siuc-nate opened this Issue Dec 3, 2018 · 29 comments

Comments

@siuc-nate
Copy link

siuc-nate commented Dec 3, 2018

These properties would be very useful to have at the Competency Framework level, as they would enable a framework to indicate its relevant industries and occupations.

We would need to retain the range of ceterms:CredentialAlignmentObject in order to continue enabling references/descriptions of industries and occupations that don't exist in some external framework.

@stuartasutton

This comment has been minimized.

Copy link
Contributor

stuartasutton commented Dec 5, 2018

Nate, I agree that we should consider the addition of these properties. BIG PUSH BACK...no alignment object.

@siuc-nate

This comment has been minimized.

Copy link
Author

siuc-nate commented Dec 5, 2018

The reasoning behind the use of alignment object here would be to allow for the (apparently somewhat frequent) cases where there is no framework to align to, and the industry/occupation is simply included by name (potentially with some web page URL to point to). This allows us to accommodate whatever data the publishing system has available while also normalizing the structure of the data for the sake of consuming systems.

@philbarker

This comment has been minimized.

Copy link

philbarker commented Dec 5, 2018

@siuc-nate using the AlignmentObject in that case seems wrong to me too. Am I understanding correctly that you want the domain to be a CompetencyFramework and the range to be an AlignmentObject, so the AlignmentObject points from the educational framework to an Occupation or Industry Type? That's not the direction AlignmentObjects usually work. Why not just point to a blank node with a label and url property? e.g (ignoring namespaces)

{"name": "my framework",
 "occupationType" : {
  "@type": "Occupation"
   "name": "dragon wrangling",
   "url": "http://hogwarts.sch.uk/carreers/dragonwrangling"
  }
}

[BTW, I don't much like the names industryType and occupationType as they have more obvious meanings when categorising Industries and Occupations; I'd suggest something like relevantOccupation & relevantIndustry]

@stuartasutton

This comment has been minimized.

Copy link
Contributor

stuartasutton commented Dec 6, 2018

Nate, if there is no framework, then use of alignment object is wrong.

@siuc-nate

This comment has been minimized.

Copy link
Author

siuc-nate commented Dec 6, 2018

Sometimes there is a framework.

If it would be preferable to override the ranges of these properties in the profile to be xsd:anyURI as opposed to ceterms:CredentialAlignmentObject then that is fine, provided we can ensure that blank nodes will have some sort of reliable structure (As always, the structure of CredentialAlignmentObject is what gives it value for my purposes; the "alignment" aspect could just as well be done away with most of the time).

@stuartasutton

This comment has been minimized.

Copy link
Contributor

stuartasutton commented Dec 8, 2018

@siuc-nate, in addition to standing by my comment above, I've always been uncomfortable with our use of ceterms:CredentialAlignmentObject as range where a specific class has been designated since the alignment object is merely a means of encoding:

To put it bluntly, these properties are intended to compel use of established frameworks.

@siuc-nate

This comment has been minimized.

Copy link
Author

siuc-nate commented Dec 10, 2018

@stuartasutton Then how would cases where there is no framework be handled? I ask because we are currently using industryType and occupationType (and I believe instructionalProgramType - @cwd-mparsons correct me if I'm wrong) to handle both framework and non-framework (i.e. plain text) alignments, per @jkitchensSIUC.

@stuartasutton

This comment has been minimized.

Copy link
Contributor

stuartasutton commented Dec 15, 2018

(Sigh) Non-framework-based industry, occupation and instructional program types are, quite simply, literals...no need for the alignment object.

@siuc-nate

This comment has been minimized.

Copy link
Author

siuc-nate commented Jan 2, 2019

So then what should the range of industryType and occupationType be? They need to handle both framework and non-framework cases (which is currently achieved through the structure provided by CredentialAlignmentObject).

@stuartasutton

This comment has been minimized.

Copy link
Contributor

stuartasutton commented Jan 2, 2019

Well, in fact, their range should be as I noted above--a thing, NOT a non-framework literal. We have had this conversation multiple times; CredentialAlignmentObject is not to be used where a rdf:langString is the solution. It is to be used ONLY where the concept being expressed is formally defined in some identified scheme. I stand what I said in #557 (comment) above (including range statements).

If we are wanting to defeat the purpose of restricting to identified schemes by allowing them to put in any text of their choosing, then we need companion properties that are defined with the range of rdf:langString...e.g., alternativeIndustryType and alternativeOccupationType.

Where else do we use CredentialAlignmentObject as a data structure for adding non-framework literals?

@siuc-nate

This comment has been minimized.

Copy link
Author

siuc-nate commented Jan 2, 2019

Alternative properties make sense, then.

@cwd-mparsons how is CIP code (instructionalProgramType) being handled? Is this implemented the same way (a combination of select existing/add your own)?

@siuc-nate

This comment has been minimized.

Copy link
Author

siuc-nate commented Jan 15, 2019

Per our 1/15/2019 meeting:

  • We will add industryType and occupationType to Competency Framework
  • We will create new properties:
    • alternativeIndustryType
    • alternativeOccupationType
  • The above properties will be added to all domains that currently use industryType and occupationType, including Competency Framework

Note: The new properties will need proper definitions before this can move forward.
This also impacts issue #559.

@stuartasutton

This comment has been minimized.

Copy link
Contributor

stuartasutton commented Jan 19, 2019

Domain of the following properties as the same as industryType, occupationType and instructionalProgramType.


alternativeIndustryType

Term: alternativeIndustryType
Label: Alternative Industry Type
Definition: Word or phrase denoting an industry where an appropriate term is not available in enumerations such as the SIC, NAICS, and ISIC classifications.
Comment: Where an appropriate term is available in enumerations such as the SIC, NAICS, and ISIC classifications, use the industryType property so the source of the term can be appropriately identified.
RangeIncludes: rdf:langString


alternativeOccupationType

Term: alternativeOccupationType
Label: Alternative Occupation Type
Definition: Word or phrase denoting an occupation where an appropriate term is not available in enumerations such as the EU's ESCO, ONET, ISCO-08, and SOC 2010.
Comment: Where an appropriate term is available in enumerations such as the EU's ESCO, ONET, ISCO-08, and SOC 2010, use the occupationType property so the source of the term can be appropriately identified.
RangeIncludes: rdf:langString


alternativeInstructionalProgramType

Term: alternativeInstructional Program Type
Label: Alternative Instructional Program Type
Definition: Word or phrase denoting an instructional program type where an appropriate term is not available in an enumeration such as CIP (Classification of Instructional Programs).
Comment: Where an appropriate term is available in an enumeration such as CIP (Classification of Instructional Programs), use the instructionalProgramType property so the source of the term can be appropriately identified.
RangeIncludes: rdf:langString

@stuartasutton

This comment has been minimized.

Copy link
Contributor

stuartasutton commented Jan 19, 2019

@philbarker, I somehow missed your comment here way back in early December. By the way, it is very nice to have someone else looking over our shoulders. I think you have the scenario correct, but I'd disagree a bit that AlignmentObject isn't an appropriate solution (although not as good as DefinedTerm). Here's your example cast through AlignmentObject:

{"name": "my framework",
   "occupationType" : {
       "@type": "AlignmentObject"
       "targetName": "dragon wrangling",
       "targetUrl": "http://hogwarts.sch.uk/carreers/dragonwrangling"
    }
}

That said, do I like this, no. Is it incorrect, no. I stand firm that the only reason for doing this at all is that you can't resolve the URI for the target and grab the name etc...but that's the RDF/linked data part of me talking.

@cwd-mparsons

This comment has been minimized.

Copy link
Member

cwd-mparsons commented Jan 21, 2019

@stuartasutton Based on the latter comment and the content of #561 , I want to confirm the format for these alternative properties.
Are they to be published as a language map list essentially like keywords?

@stuartasutton

This comment has been minimized.

Copy link
Contributor

stuartasutton commented Jan 21, 2019

Yes, they have a range of rdf:langString. So, I assume that means language maps.

@cwd-mparsons

This comment has been minimized.

Copy link
Member

cwd-mparsons commented Jan 22, 2019

@stuartasutton
We have Naics as a convenience property to enter just a list of Naics codes. Should we also add similar properties for a list of O*Net and CIP codes?

@stuartasutton

This comment has been minimized.

Copy link
Contributor

stuartasutton commented Jan 22, 2019

I don't understand, by "add similar properties" for NAICS codes.

@siuc-nate

This comment has been minimized.

Copy link
Author

siuc-nate commented Feb 8, 2019

Changes made in pending CTDL (not yet in history tracking):

  • Added ceterms:industryType to ceasn:CompetencyFramework
  • Added ceterms:occupationType to ceasn:CompetencyFramework
  • Created ceterms:alternativeIndustryType as outlined above (domains: CredentialOrganization, QACredentialOrganization, Credential + subclasses, AssessmentProfile, LearningOpportunityProfile, CompetencyFramework)
  • Created ceterms:alternativeOccupationType as outlined above (domains: Credential + subclasses, AssessmentProfile, LearningOpportunityProfile, CompetencyFramework)
  • Created ceterms:alternativeInstructionalProgramType as outlined above (domains: Credential + subclasses, AssessmentProfile, LearningOpportunityProfile)

Outstanding questions:

  • Should ceterms:instructionalProgramType be added to ceasn:CompetencyFramework?
  • Should ceterms:alternativeInstructionalProgramType be added to ceasn:CompetencyFramework?
@siuc-nate

This comment has been minimized.

Copy link
Author

siuc-nate commented Feb 8, 2019

Per our 2-8-2019 Meeting:
We will not add instructionalProgramType/alternativeInstructionalProgramType to CompetencyFramework until some need for it is demonstrated.

@stuartasutton

This comment has been minimized.

Copy link
Contributor

stuartasutton commented Feb 12, 2019

One lingering concern. Every time this thing/string need arises, we cannot/should not create "alternative" properties. This has been solved (perhaps inelegantly) in several large German bibliographic services as well as elsewhere through declaring the property as requiring a thing and using bnodes to handle literals (without declaring any new properties).

With URI

<http://id.meineInstitution.de/12345> 
    dct:creator <http://id.meineInstitution.de/Bergmann_Bertram>.

Without URI

<http://id.meineInstitution.de/12345> 
    dct:creator [ rdfs:label "Bertram Bergmann" ].

image

@siuc-nate

This comment has been minimized.

Copy link
Author

siuc-nate commented Feb 12, 2019

That is more or less what we've been trying to accomplish with CredentialAlignmentObject (playing the role of the bnode) - the difference of course being that the CredentialAlignmentObject is always present. I can see the benefit of using bnodes instead, especially if we make that a consistent solution in other places where the need to "point to something that may or may not exist" keeps coming up (such as pathway components).

@siuc-nate

This comment has been minimized.

Copy link
Author

siuc-nate commented Feb 12, 2019

Per our 2-12-2019 meeting:

The three "alternative" properties will be removed from pending; instead the problem will be solved via the blank node solution @stuartasutton outlines above.

@siuc-nate

This comment has been minimized.

Copy link
Author

siuc-nate commented Feb 12, 2019

Per our 2-12-2019 meeting:
Turtle example:

@prefix ceterms: <http://purl.org/ctdl/terms/>.
<http://123> a ceterms:Diploma ;
	ceterms:industryType <http://abc>, <_:ABC>.

<_:ABC> a ceterms:IndustryClassification ;
	ceterms:name "Cybersecurity"@en-us.

Equivalent JSON-LD graph:

{
	"@context": "https://credreg.net/ctdl/schema/context/json",
	"@graph":[
		{
			"@id": "http://123",
			"@type": "ceterms:Diploma",
			"ceterms:industryType": [
				"http://abc",
				"_:ABC"
			]
		},
		{
			"@id": "_:ABC",
			"@type": "ceterms:IndustryClassification",
			"ceterms:name": { "en-us": "Cybersecurity" }
		}
	]
}
@stuartasutton

This comment has been minimized.

Copy link
Contributor

stuartasutton commented Feb 12, 2019

Nate, just a slight variation:

TURTLE

@prefix ceterms: <http://purl.org/ctdl/terms/>.
@prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> .

<http://123> a ceterms:Diploma;
	ceterms:industryType <http://1234.com/indust234>, [rdfs:label "Cybersecurity"@en-us].

JSONLD

{
  "@context": {
    "ceterms": "http://purl.org/ctdl/terms/",
    "rdf": "http://www.w3.org/1999/02/22-rdf-syntax-ns#",
    "rdfs": "http://www.w3.org/2000/01/rdf-schema#",
    "xsd": "http://www.w3.org/2001/XMLSchema#"
  },
  "@graph": [
    {
      "@id": "http://123",
      "@type": "ceterms:Diploma",
      "ceterms:industryType": [
        {
          "@id": "_:ub199bL4C52"
        },
        {
          "@id": "http://1234.com/indust234"
        }
      ]
    },
    {
      "@id": "_:ub199bL4C52",
      "rdfs:label": {
        "@language": "en-us",
        "@value": "Cybersecurity"
      }
    }
  ]
}
@siuc-nate

This comment has been minimized.

Copy link
Author

siuc-nate commented Feb 13, 2019

No, we want to avoid unnecessary use of @id objects - that was one of the driving factors behind us switching to use @graph and blank nodes to begin with, otherwise we'd do this (which is the old way of doing things and resulted in lots of @id objects that were very irritating:

{
  "@context": {
    "ceterms": "http://purl.org/ctdl/terms/",
  },
  {
    "@id": "http://123",
    "@type": "ceterms:Diploma",
    "ceterms:industryType": [
      {
        "ceterms:name": {
        "en-us": "Cybersecurity"
        }
      },
      {
        "@id": "http://1234.com/indust234"
      }
    ]
  }
}
@siuc-nate

This comment has been minimized.

Copy link
Author

siuc-nate commented Feb 13, 2019

Did any of your example get generated by a converter? I did notice the context didn't indicate that ceterms:industryType was an @id property (and the unnecessary expansion of the language map). I think this is closer to what you're looking for:

{
  "@context": {
    "ceterms": "http://purl.org/ctdl/terms/",
    "ceterms:industryType": {
      "@type": "@id"
    }
  },
  "@graph": [
    {
      "@id": "http://123",
      "@type": "ceterms:Diploma",
      "ceterms:industryType": [
        "_:ub199bL4C52",
        "http://1234.com/indust234"
      ]
    },
    {
      "@id": "_:ub199bL4C52",
      "ceterms:name": {
        "en-us": "Cybersecurity"
      }
    }
  ]
}
@siuc-nate

This comment has been minimized.

Copy link
Author

siuc-nate commented Feb 13, 2019

I have removed alternativeIndustryType, alternativeOccupationType, and alternativeInstructionalProgramType from pending CTDL per the meeting referenced in the earlier post:
#557 (comment)

@siuc-nate

This comment has been minimized.

Copy link
Author

siuc-nate commented Feb 14, 2019

This has been noted in the history tracking.

The ongoing discussion should continue in #574.

@siuc-nate siuc-nate closed this Feb 14, 2019

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.
You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session.