Scope of this draft spec and level of granularity

[kimdhamilton]

Per discussion last week, we should refine the scope and level of granularity of this draft spec and move other issues outside.

Starting point with scope:

1. Represent skills
2. More formal education (e.g. diploma)
3. Informal education (e.g. webinar attendance)

We can continue to iterate in this issue

[kimdhamilton]

out of scope:

• XML mapping
• Image integrity - general
• PDF as container

[kayaelle]

Has there been discussion to include evidence or documentation like Open Badges have? Whether as a link or embed or other ideas?

[kimdhamilton]

PR submitted by Anthony Camilleri, but per 9 Nov meeting decided to abstract into pseuodcode to avoid confusion around intent. I.e. restate the concepts in pseudo code
 vs json-ld

[philbarker]

Regarding PR #18 would it be useful to try to relate the entities and relationships required to schema.org Action and subtypes such as the PerformAction, AchieveAction and CTDL's CredentialingAction

I've sketched the outlines of examples similar to those in Anthony's PR (without much detail, lots more could be added, forexample there is no reason there couldn't be a direct hasCredential link from the Person to the Degree as well as what is shown)

[kimdhamilton]

Sorry @philbarker, I just noticed this. Let's review tomorrow.

[kimdhamilton]

additional concept not included in Anthony's PR: completion of a course/program #22

[philbarker]

Link to updated versions of diagrams above: https://drive.google.com/file/d/17sQHMRlc6wS5cgEUOmBVB9GiUKouCL_I/view?usp=sharing

[kimdhamilton]

Notes on reverse navigability: to avoid the need to add different properties on Person for different Action subjects, perhaps we can think of a good generic property.

In other words, instead of needing to add properties like achieved, performed, (or hasX variants), is there a generic property that would work? For example Person executed/hasExecuted Action.

Directly flipping agent is awkward: isAgentOf. And @philbarker already pointed out possible confusion of using did.

[philbarker]

It may be that achieved and performed are the properties we want, but they should point to an AchieveAction or a PerformAction. Adding (a small number) of new properties wouldn't bother me if doing so lead to greater clarity of the meaning in an educational context. But I don't think we need whole new object types to contextualise what those properties entail.

Q: do we need a distinct property-Action pair for each use case?

JSON-LD has the "syntactic sugar" of @reverse that offers at least a fall-back option if creating reverse properties is not feasible. So

{
  "type": "Person",
  "id": "#me"
  "@reverse": {
    "agent": {
       "type": "Action",
       "description": "what I did",
       ...
    }
  }
}

It's not perfect, but worth bearing in mind as a last resort.

[kimdhamilton]

Q: do we need a distinct property-Action pair for each use case?

My personal preference would be to avoid adding a property per Action, and instead have a single property that applies to Action subtypes -- primarily because it feels redundant.

I didn't know about @reverse -- also interesting. But I'd be interested in seeing if people think there's a single property we can add. I expect this to be a very common style of EDU VC, so it would be nice to avoid something that's awkward