parsing the prefix correctly

[akeshavan]

We are making a dangerous assumption here: https://github.com/ReproNim/schema-ui/blob/master/src/components/Survey/Survey.vue#L217

That the context prefix we are using maps directly to the name of the jsonld file. We need this because the prefix is how we are defining the scoring and branching logic. @satra when we do jsonld.expand on an activity, we lose the prefixes that we defined in @context -- do you know of a way to recover them?

[sanuann]

jsonld.compact reverses the expand action as far as I know.

[akeshavan]

Actually, we should just define the mapping separately.

@sanuann can you add another field in schema-standardization that preserves the mapping between items that are used to evaluate scoringLogic and branchingLogic?

[akeshavan]

I just realized you can string multiple prefixes together, so jsonld.compact might not help

EDIT: compact-ing doesn't help

[akeshavan]

compact doesn't seem to hel

[sanuann]

Didn't get you. Why doesn't compacting help?

[satra]

this is an issue, but since scoring and branching are javascript code. that's not a clean implementation, and something has to translate the javascript variables to "values/keys" outside that scope. i expect that to help with the mapping. this can be done prior to expansion, but i would not put in the schema.

the other way is to get the mapping from the id of the jsonld file:
https://github.com/ReproNim/schema-standardization/blob/master/activities/PHQ-9/items/phq9_1.jsonld#L6

the most important thing that we need to get out of this is that response keys are URIs to items and response values are a literal or a controlled dictionary.

[akeshavan]

I noticed that the @id get expanded as well. But @sanuann just told me that Redcap uses "altLabel" to refer to variables in equations, so I'll add an issue to implement it that way instead

[shnizzedy]

Losing context shouldn't be an insurmountable issue; well-formed IRIs should resolve to include or link to all of the necessary context, right?

[akeshavan]

Let me restate the problem, this might help with my confusion:

1. The main goal of this project is to be able to reuse items. So items have a unique ID, e.g. a URI.

2. In JSONLD, we define a prefix so we can refer to these URIs without typing them out. When the jsonld is expanded, these prefix are replaced with the URI.

3. We need to define branching and scoring logic, in terms of the items. In the current implementation, we refer to the items, again, with their prefix.

4. But when we expand the JSONLD, these prefixes aren't replaced with URIs, which means we need to figure out this mapping, somehow!

Our hack for getting this to work quickly was that I noticed we named our files with the same name as the prefix. But, as we move to a schema-server for all this, we can't make this filename assumption.

Here are the workarounds I can think of:

1. encode once again the prefixes to URIs separately in the activity
2. use the altLabel of the item. as the mapping instead.. but I don't like this because we can't assume this will be unique, so I'm nixing this.
3. use the @id of the item, but a) this gets expanded, and b) this should be a unique id (because if we are reusing items, there shouldn't be a clash on ids). Since it will be unique, it might not have a human-meaningful name to refer to in formulas, so i'm nixing this too.
4. figure out how to extract those prefixes again. Are our jsonld's not formatted correctly? A hack for this would be to load the jsonld as a JSON, and then expand its contents using the library.

Any other ideas?

[shnizzedy]

I don't follow 2‒4 in the problem restatement.

When the jsonld is expanded, these prefix are replaced with the URI.
…
But when we expand the JSONLD, these prefixes aren't replaced with URIs

The whole point of JSON-LD prefixing is that expanding the prefix + the suffix results in a dereferencable IRI. In Mindlogger, the entity ID can be encoded; on GitHub, the raw URL. If the prefix:suffix doesn't expand into a dereferencable string, the syntax is incorrect. We don't need to know or care about filenames so long as we have an API that can route us based on these strings.

compact IRI
A compact IRI is has the form of prefix:suffix and is used as a way of expressing an IRI without needing to define separate term definitions for each IRI contained within a common vocabulary identified by prefix.

[akeshavan]

On the jsonld playground: https://json-ld.org/playground/

if you copy/paste the PHQ-9 activity: https://raw.githubusercontent.com/ReproNim/schema-standardization/master/activities/PHQ-9/phq9_schema.jsonld

and look at the expanded result, there is no way for me to know that phq9_1 corresponds to https://raw.githubusercontent.com/ReproNim/schema-standardization/master/activities/PHQ-9/items/phq9_1.jsonld

This is a problem because I refer to it in the "visibility" section, to calculate whether or not to show an item. I'm not familiar with jsonld enough to know how to keep the mapping in the expanded result.

The whole point of JSON-LD prefixing is that expanding the prefix + the suffix results in a dereferencable IRI. In Mindlogger, the entity ID can be encoded; on GitHub, the raw URL. If the prefix:suffix doesn't expand into a dereferencable string, the syntax is incorrect. We don't need to know or care about filenames so long as we have an API that can route us based on these strings.

The problem is that prefix:suffix DOES expand into a dereferencable string, but it isn't happening in the branching logic or scoring equation sections. And we lose the reference in other places (which is correct behavior)

[satra]

@akeshavan - you cannot. the expanded form is a graph, which is why there is a mismatch between using keys (for json simplicity) in scoring/branching, when the underlying data model has no concept of it. we are also taking account of a default vocabulary that let's us use those string keys without a prefix.

there may be a middle ground, but i do want to think about this more carefully. let's not hack a hack at this point and solve it with a proper solution.

[akeshavan]

@satra any ideas? :)

[sanuann]

@satra aren't we using the variableMap now to resolve this?

[satra]

yes. closing.