remove errant jsonldPredicate

[mr-c]

This was fix was confirmed to remove the phantom "package" errors, see common-workflow-language/cwltool#229

[mr-c]

@tetron I believe this explains common-workflow-language/cwltool@0433da3#diff-beaffd47be66a8d26cd63bd075ab9310R39 :-)

[mr-c]

The intent when I wrote the SoftwareRequirement feature was to indicate that the package field was an identifier. @tetron Perhaps I did use the json-ld @id concept correctly and it triggered unexpected code paths -- I'm struggling with the json-ld specification so your assistance is appreciated.

[tetron]

Background:

"@id" alias fields indicates node anchors in the graph, and they trigger special handling. For example, they go into the Loader index. Nodes which have an "@id" field can be $imported in several places and will be references to the same node.

In order for file roots lacking an explicit "id" to go into the index, the loader adds an synthetic "id" field containing the URI at which the file was loaded. However, there are actually multiple "@id" aliases: "id", "name" and "package". Unfortunately, at the point that the "id" field is being added, the Loader doesn't know what type it is validating for, so it adds all of those fields. This is where the phantom "package" field comes from. Downstream validation is then explicitly instructed to ignore the alternate "@id" fields.

Thoughts:

• Having multiple "@id" aliases is unfortunate and the handling is a bit hacky. We could get rid of "name" and "package" and just use "id" consistently, but that would be disruptive for a post-1.0 change.
• "SoftwarePackage" is currently not cross referenced within a CWL document the way that parameters and workflows ports are, so treating "package" as a special field is unnecessary.
• I think what we were trying to accomplish was an upstream package reference "for more information" such as a website, github, bio.tools, RRID, DOI, etc. However, this is at cross purposes with @jmchilton's desired use of the field which is to have a common name that's assumed to be the default package name.
• External URI references are indicated by _type: "@id. This means the field is an outgoing reference, rather than an identifier for the current node. These get link-checked by default, there's a way to specify non-link checked URI fields:

      jsonldPredicate:
        _type: "@id"
        noLinkCheck: true

• specs are not marked as URI noLinkCheck fields, but they probably should be.
• The website, github, bio.tools, RRID, DOI, etc links could be in specs
• We shouldn't rush in features for which no implementation work has been done :-(
• A use case to consider is to be able to reference an upstream CWL package definition:

hints:
  SoftwareRequirement:
    packages:
      - {$import: http://bio.tools/tool/bwa/package.cwl}

http://bio.tools/tool/bwa/package.cwl

package: bwa
specs:
  - http://debian.org/packages/jessie/bwa

[tetron]

Recommendations:

• package field becomes a simple string (possibly optional?) documented as "default package name".
• specs becomes jsonldPredicate: {_type: "@id", noLinkCheck: true}

Resolver behavior should start with specs and then fall back on default package name. Allow for resolvers to include an additional level of indirection by getting packaging links from indexes such as bio.tools and RRID.

[mr-c]

Thank you @tetron for your detailed backgrounder.

I agree, the @id alias doesn't belong on the package field, hence this PR and common-workflow-language/cwltool#229

I'll add the specs change and leave further changes (except, perhaps, my clarification in #343 ) for later versions of the spec.