Do we want to make it so activities can be deprecated?

Some support in working group, parallels other usage. But good to work through use case first.

“This specification describes how to author an xAPI Profile.” This is the first sentence of the doc. Perhaps we should change this from “author” to “represent” or “publish” or something else? We will develop tools for people to publish profiles, but we don’t want them to manually “author” anything in RDF/JSON-LD on their own. The way the word author is used here seems to imply they will be expected to manually create these files themselves, which isn’t the case. That would result in a lot of errors, typos, human errors, etc. “Author” is used in second sentence as well. Pretty much anywhere we say “author” we should come up with a more representative term. I know this is somewhat explained later when talking about a “profile” server’s capabilities. But I’m not fond of the term, “author” in this context. We can discuss this further if you guys feel there is a good reason to stick with this term. The only exception is that it seems to make sense to use the term “author” when referring to the provenance metadata of the profile (the creator or author).

Right now most fields are not marked as optional, and a few that aren't probably should be. An important consideration while reviewing for this is, in many cases it will not be possible to understand how to use the profiles without extensive metadata -- verbs need definitions, and patterns of statements need descriptions of what they mean, and so forth. That suggests most of the descriptive metadata should stay required.

I think it should relate to timestamp but that could be difficult to validate as at any point in time there could potentially be more statements on their way that would satisfy the pattern.

Consider if a limited subset of "scripting" (the parts that don't look like scripting) will be supported, or not at all. Everything else should be straightforward, though should probably be briefly noted.

This allows the LRC to identify that the statement follows that profile.

See for example https://github.com/AICC/CMI-5_Spec_Current/blob/quartz/cmi5_spec.md#context_activities_category_cmi5

The section “Profile Metadata” appears to focus on the properties associated with these things . Suggest we use some consistent names here and keep it consistent with how we described things in the vocab spec, using RDF constructs/nomenclature such as classes and properties (where it makes sense).

Based on the draft profile spec, a few new classes and properties should be created in the core ontology. Please confirm we need to add the following to the xAPI Ontology, https://w3id.org/xapi/ontology# and verify that I’m proposing the correct way to represent these (in parenthesis below). I probably need to update this anyway to express Extensions correctly and make it consistent with how it is being proposed in the profile spec.

Classes

• Profile(subproperty of skos:ConceptScheme?)
• Author (subproperty of prov:Agent ?)

Properties

• name(subproperty of skos:prefLabel ?)

• definition (subproperty of skos:definition ?)

• seeAlso(subproperty of rdfs:seeAlso ?) - Need to point out in the description that this doesn’t need to be same thing as the profile IRI. A good example might be using a URL pointing to the cmi5 profile project URL or the scorm profile project URL.

The following are conveyed in the external JSON-LD @context mapping. Is there any benefit to expressing any of these properties the xAPI ontology instead of context? If so, which ones? I will probably need Russell’s help with this.
@context Mapping

• versions (array of xapi:Profile objects, using prov:SpecializationOf)

• concepts(reverse of xapi:inProfile) - inProfile is not defined yet (perhaps Profile is a skos:Concept and the concepts list is subproperty of skos:inScheme?) - also in the vocab spec we grouped concepts by verbs, activity types, etc.

• templates (undefined so far in the spec) - Do weed a way to search for statement templates independent of the profiles they are associated with? In other words should templates be a specific type or Concept like verbs and activity types? If so, we probably need to create a new class for this, such as xapi:StatementTemplate

• patterns (undefined so far)

Deprecated URIs shouldn't happen, but have and will happen.

It would be good to have a way for a profile to identify URIs that a LRP implementing a profile shouldn't use, but which a LRC reading statements conforming to profile (possibly including earlier versions) will need to support.

Right now, pending context finalization, they're in shorthand

This is the @id field, used for internally referring to templates and patterns within patterns. Needs to produce a blank node or a profile namespaced node and be preserved through compaction.

JSON Schema can restrict a value to a primitive -- string, number, boolean -- which is one common way extensions are currently being used (though this standard will hopefully encourage more structure). Good to describe how to accommodate them, and how to validate them without using a full JSON Schema library.

Note: include putting the extension URI inside the given context? Breaks context-as-guidelines model a bit, but JSON Schema seems to repair that?

A Statement Template describes one way statements following the profile may be structured. Which statement template applies is determined by the verb, object activity type, and attachment usage types in the statement. If the verb, object activity type, and all attachment usage type(s) are present and the profile is used as a category context activity, the rules in the Statement Template MUST be followed.

This seems to be saying "if a statement fully conforms to a template then it must conform to that template". There's got to be a better way. I'd be inclined to tie templates to verb ids.

This sentence needs to be more sentencey.

First up, the extensions placement property seems to be doing two separate things:

1. Determining where in the statement the extension can be used.
2. Determining which activity types an extension is valid to be used with.

These should be split out into separate properties (if we keep both parts).

Second, it seems odd to be restricting statements to certain activity types like this. Why not use Statement Templates instead?

Third, do we really want this to be an array? Surely extensions should always be used in the same place? If it is an array (maybe to support using a profile to document real life usage), should we strongly recommend the array only has 1 value?

I don't think we should re-define activities here. We should just reference the xAPI spec.

Is there any particular desperate need for adding the @ in front of the id?

Statement Templates are easier to think about when they are unique within a profile. We should add language encouraging uniqueness, possibly additional constraints preventing certain sorts of non-uniqueness, and guidance on how to easily achieve uniqueness (such as putting a verb or objectActivityType in every template, and making them all different, since a statement can only have one).

Brought up in #8. Partially addressed in #49.

May eventually need to be inlined as string, but would be nice to include in the document's JSON if possible.

It would be good to include a summary of the purpose and goals of the spec. My goals in contributing are encapsulated in these questions which I'm using to review the document:

1. Would profiles defined following this spec contain enough information for a Learning Analytics Platform
   (specifically Watershed) to automatically and without human intervention generate useful reports from the data?
2. Related to item 1, would profiles defined using this spec be prescriptive enough to ensure LRPs implementing the profile are consistent enough in their statements to facilitate item 1?
3. Are the profiles easy to create? The biggest problem with profiles today is the lack of anybody publishing them. The spec should make it easier to create profiles, not harder.

A short note should help people make good URIs for versions.

It looks like the pattern element names have changed but the values column and the text below the table have not been updated.

I noticed all concepts are lumped into a concepts list in JSON-LD. For the vocab spec we have each concept grouped into lists. For example, verbs[ ], activity types [], etc. For an example, look at the current video vocab/profile JSON-LD doc: http://xapi.vocab.pub/datasets/video.jsonld. Would there be any benefit to keeping that same granularity of list concepts or is it better to lump everything into general “concepts”?

I'd be inclined to delete both because I don't know what alignments are and I don't see why statement references need special treatment.

edit: original text is preserved, but see discussion for how this moved to being about dependent rules for statement templates

The descriptions for the any and all statement template properties are not clear. We also need examples. My understanding from the descriptions is that this is a value statement template:

"requirements": [
    {
        "location": "context.contextActivities.grouping[0]",
        "rule": "included"
    },
    {
        "rule": "included"
        "any": [
            {
                "location": "result.score.scaled"
            },
            {
                "all": [
                    {
                        "location": "result.score.raw"
                    },
                    {
                        "location": "result.score.min"
                    },
                    {
                        "location": "result.score.max"
                    }
                ]
            }
        ]
    },
    {
        "any": [
            {   
                "rule": "included",
                "location": "object.definition.name"
            },
            {   
                "rule": "excluded",
                "location": "object.definition.description"
            }
        ]
    }
]

Note the placements of the rule properties in the above. Should we require the rules to always be on the same level as the related location property?

Feedback on this section below.

• Update this draft context to use https://w3id.org/xapi/ontology# instead of http://purl.org/xapi/ontology#

• Also, the context we’ve been using for vocab is here: http://xapi.vocab.pub/vocabulary/context.jsonld
  Are there any issues with this?

• Should we have a separate context document for vocabulary than we do for profiles or should they be combined?

Is verb required, in particular? If verb isn't included, is object activity type required? And so forth.

Since SKOS and PROV feature a few times in the document, it would be helpful to add some short definitions of each and their relevance for those not familiar with them. This is started in Technical Foundations but more detail would help.

ADL is building out a public server for the community based on the direction of the profile effort. ADL will run it initially, but we will eventually put mechanisms in place so that it can be self-sustaining and curated by the broader community. We do need to work together on figuring out the curation process at some point. Rob Chadwick already has some functionality built using RDF, SPARQL, and JSON-LD and has been basing it on the vocab spec. He will be adding new requirements and functionality based on these new profile requirements. We hope work together get some feedback from you and the community on building the queries and other resources for using the profile/vocab server in the future as we make more progress.

The former is mostly ready, but the latter is not, and should be done by taking an extant EBNF matching algorithm and restating/adapting it.

contextGroupingActivityType and so forth, each array valued and with the same rules for matching as attachmentUsageType

Using @id will require it to be a URI. In many ways this is good, as it provides all the namespacing benefits of URIs. But the xAPI spec allows anything in stateId and profileId, and, notably, cmi5 uses non-URI values.

How best to allow that? Do we allow that (probably)?

In issue #17 (closed) I pointed out we need more clarity on the difference between vocabulary and profiles (or merging them into a single concept of profiles as Russell proposed). However, we also need to determine the level of granularity allowed for profiles (or clearly specify the different types of profiles supported in xAPI). I'll try to explain in bulleted sections below.

1. First let's talk vocabulary vs profile. ADL created a vocabulary list (https://w3id.org/xapi/adl), and it also has a specific profile (SCORM) that uses the vocabulary. The SCORM profile (https://w3id.org/xapi/scorm) also defines additional types of properties that are used specifically in that profile. The SCORM profile exclusively uses the ADL vocabulary terms but also defines additional custom data elements within the profile to address concepts unique to SCORM (e.g., attempt state, temporal model). Another example of this is medbiquitous. They have a core vocabulary list of terms they plan to add to, but plan to build out several different profiles over time based on their various medical scenarios or use cases. The have already built one (virtual patient), but anticipate the need to create additional profiles in the near future. So my question here...isn't there a need to have vocabularies and profiles as separate datasets? If we merge them together conceptually then it opens up more questions on how to deal with the current ADL & medbiq vocab terms as well as older xAPI terms and old practices from activity streams, tincan, etc. For example, if we merge the ADL vocab and SCORM profile together then are we saying that ADL terms are only skos:inScheme of the SCORM profile? If so, that's fine we just need to figure how to handle all of the older IRIs and associate them with certain profiles. It also might impact IRIs and content negotiation. For example, if you GET the SCORM profile IRI it returns all of the SCORM profile data, not just the vocabulary dataset/list or even the individual terms.

In addition to distinguishing between vocabularies and profiles there are larger, existential questions about just profiles. See (2) below.

2. What are the different types of profiles? It seems we currently have the concept of what I'm calling a "project profile" that may define a vast amount of custom properties, vocab, and extensions. Project profiles seem to be rather large implementations that are based on other specifications, concepts, or broader use cases. In addition to SCORM, cmi5, IEEE ADB, and Medbiq virtual patient project profiles, another example of a project profile is Across X: https://w3id.org/xapi/acrossx. In addition to these project profiles (e.g., cmi5, SCORM, IEEE ADB, Across X), more granular types of "activity-based profiles" can be created to represent specific implementations of learning activities. For example, activity profiles (e.g., assessment or video) can be used as a stand-alone profile or within a broader project profile. This is similar to the granularity that IMS Caliper is attempting to achieve where they have the concept of "metric profiles" for very discrete event-based activities such as posting or interacting with a discussion forum, media (audio/video), etc. These metric profiles can then be reused inside of any type of implementation. I think it's important that we recognize the potential levels of granularity here when talking about profiles. They could be very small reusable profiles or they could be very specific implementations with lots of requirements and not very reusable. Should the more granular types of profiles be activity/event based? Should they only be project / specification based? Or both? Do we need tighter control / governance over granular profiles (those that have the most reuse potential)?

3. I'm not sure "project profile" vs "activity profile" is the best way to describe these. Any thoughts on normalizing the terminology and concepts around profiles is much appreciated. It seems like we need to step back and figure this out. It has big implications on how people will understand the importance of profiles, but also will have bigger implications on the interoperability & validation of profile data in general, and also in how we will develop tools to support creating/authoring and publishing profiles.

Missing y https://github.com/DataInteroperability/xapi-profiles/pull/47/files#diff-3c9e7e6aa54ed9f243c315fce4dba934R147

For example, a profile with no patterns presumably allows statement templates to be used freely. Should that be extended to statement templates not used in patterns generally? The idea is, any statement template not used in any pattern has an implicit pattern of "sequence": ["the template's identifier"], which is basically equivalent to saying "you can send a single statement matching this pattern all you want".

Clearly this is not intended to be in the final spec:

This is the trickiest bit, probably, along with the idea of constraining document resources. The below is intended to be very preliminary.

Just making sure we've got an issue in.

https://github.com/DataInteroperability/xapi-profiles/blob/master/xapi-profiles-spec.md#using-profiles-in-statements

The term "producer" is not defined, but from the context I assume this refers to what xAPI calls a Learning Record Provider or LRP. If that's right, let's use the same term as xAPI.

Right now isn't very clear, though I think the included capabilities are mostly right. Examples will be good.

For the sake of scope and focus, I propose that we get rid of the communication and validation sections, at least for the initial release.

Let's just focus on getting a solid json structure for profiles and worry about standardizing transmission and validation later, once people start trying to transmit and validate statements against them.

Maybe we can move that information to a wiki or slack or something for now.

Which statement template applies is determined by the verb, object activity type, and attachment usage types in the statement. If the verb, object activity type, and all attachment usage type(s) are present and the profile is used as a category context activity, the rules in the Statement Template MUST be followed.

This block, while I like the approach, is confusing to read and seems to be putting the cart before the horse. We should re-word it to make clearer that LRPs generating statements following a profile should follow the templates to determine the identifiers (and other properties) to use, and LRCs reading statements should look specifically to the verb activity type, any attachment usage type(s) and the profile (version) id to determine which template is being followed and validate/process the rest of the statement accordingly.

We should also state that a profile version MUST NOT have two statement templates that use the same verb, activity type and attachment usage type(s) combination as these essentially act as a composite id for the template in a more real way than the actual id property. Alternatively, we could require the statement template id to be included in statements and expect LRCs to use that to determine which template is being followed.

A pattern is determined by a given registration — all statements within a Pattern MUST use the same registration, and statements not part of a Pattern MUST NOT use the same registration as any that are.

Could a LRP satisfy this requirement by not using the registration property at all but meeting the requirements of the pattern across all statements for each learner? (i.e. the uniqueness of the actor replaces the uniqueness of the registration).

As part of our work for this group should we also consider what others are doing and their approaches to profiles and RDF? What are we aligning our practices with? I think this would be useful information for everyone to have some context around our approaches in the profile spec. Also, do we need to improve our definition of profile?

1. Here are some definitions worth examining:

“The tailoring of a specification to suit the needs for its application to a particular community. The source schema is the original schema being profiled, whilst the derived schema is the output of the profiling activity.”

-Application Profiles (2005), IMS Global Learning Consortium

“A profile is defined not to alter the semantics of the resource representation itself, but to allow clients to learn about additional semantics (constraints, conventions, extensions) that are associated with the resource representation, in addition to those defined by the media type and possibly other mechanisms.”

-RFC6906 (2013), Internet Engineering Task Force (IETF)

“Each profile provides a common/structured vocabulary / concepts and terms for describing events such as annotating a document, starting an assessment or grading an outcome. Extending the model involves adding a new profile or enhancing an existing one.

-Caliper Analytics (2015), IMS Global Learning Consortium

“A profile is a specific set of rules and documentation for implementing xAPI in a particular context. Profiles generally provide a particular vocabulary of terms, some created specifically for the profile, and some are referenced from other vocabularies.”

-xAPI Specification (2015), ADL

2. Comparing Practices around Vocabulary & Profiles

The W3C Activity Streams & W3C Annotation group both adopted the concept of "application" profiles and also use RFC 6906 below by using the profile parameter and using link to context in the header.

https://www.w3.org/TR/activitystreams-core/#iana

https://www.w3.org/TR/annotation-vocab/#prefercontainediris

Hypermedia & The Profile Link Relation RFC6906 defines a link relation called “profile.” JSON has no semantics and isn’t specified to work with RFC6906, but JSON-LD does! You can link to a profile within the Content-Type header by adding a “profile” parameter to the media type. More info here on media types: https://www.iana.org/assignments/media-types/application/ld+json

For Example:

Content-Type: application/ld+json;profile=“https://w3id.org/xapi/video” and the URI of the profile is where you define custom properties and semantics of the data.

The W3C Annotation Spec has a core ontology/vocabulary and also allows for extending the data model using JSON-LD @context.
https://www.w3.org/TR/annotation-vocab/

Dublin Core profile guidelines (Description Set Profiles):
http://dublincore.org/documents/profile-guidelines/

Credential Transparency Initiative
The word "vocabulary" is used here to refer specifically to a set of terms, a set in which the members are properties, classes, concept schemes, and/or data types. ADL has been attending the credential registry meetings and is interested in vocab and profile compatibility with their approach to vocabulary and profiles.

http://credreg.net/ctdl/handbook
http://credreg.net/ctdl/frameworkschema

IMS Open Badges:
A Profile is a collection of information that describes the entity or organization using Open Badges. Issuers must be represented as Profiles, and recipients, endorsers, or other entities may also be represented using this vocabulary. ADL is interested in vocabulary and profile compatibility with Open Badges and Caliper.

https://openbadgespec.org/#Profile

xAPI Data Model, Use of Context and Extensions
Currently, in many xAPI implementations I've seen we are pushing so much data into non-reusable, custom extensions. I hope this addressed by the profile WG. xAPI created the idea of “context” and “extensions” as additional buckets to store more useful data related to the activity long before JSON-LD was released/mature. Now with the focus on profile data that is more semantically interoperable and reusable using JSON-LD it seems we should at some point re-evaluate the core xAPI statement model and leverage JSON-LD where it makes sense. The object nesting and structure in the xAPI Statement Data Model seems odd and should be flattened in some areas (e.g. properties in Activity Object, Activity Definition Object). I believe this was because xAPI was originally based on simple JSON structures only.

Perhaps this is a bigger spec update? Or not? At some point it should be discussed with this group whether it is feasible or should be part of a major version of xAPI. It seems our use of "context" and "extensions" is wildly different from modern JSON-LD implementations, which could be just fine. It could also lead to confusion simply because of the similar reserved name usage of "context" and "extensions."

The JSON-LD context is right now just a partial/old one that needs to be updated with all the properties in the document (including ones required for JSON Schema inlining if that's done, for example), and then verified by running test documents using it through compaction and verifying the output is unchanged.

As came up in #28

Needs some explanation before or after the table as to what this is.

I'm not clear on the purpose of altLabel I get that it's an alternative, non-preferred label, but is restrictive or suggestive? I.e. am I allowed to use a verb display that is not either the preferred or alternate label for that verb?

If it's suggestive, then why have it? We have the label that we want people to use, why suggest another one?

I don't see any reason for it to be restrictive - why limit people from using any alternative label?

In any case, if we keep it then it should be a language map of arrays (a list of values per language). There's no reason why there should be exactly 1 alternative.

"requirements": [
    {
        "location": "context.contextActivities.grouping[0]",
        "rule": "included"
    }
]

The example given seems to saying that we can use the index of arrays to require index + 1 items to be included in that array. If that's the case, we should make that clearer.

We should also make clear that the order of context activities is important when following profiles, for example a profile could theoretically require the first grouping to exclude a particular extension and the second one to include it. Or, if it's not intended that order is important, we should change how we handle arrays to make that not the case.

in xAPI verbs have a display property for their human readable component. Activity types and attachment usage types have no human readable component.

For consistency with xAPI I think we should stick with display instead of label.

USage should be Usage

I wonder if it's worth adding the following to the potential values of statement:

• recommended - the LRP is recommended to use this statement property but the LRC cannot expect it to be always included.
• optional - the LRC might want to look out for this property and use it if included, but there's no expectation on the LRP to provide it.