Rework ScholarlyArticle

[HLWeil]

• It is not clear from the profile which property in the profile maps to which property in ISA
• PubMedID might be number, must not be an URI
• naming of fields seems a bit forced

Maybe a possible solution might be to use the Identifier field and use PropertyValues to create combinations of a context for describing what kind of resource is being referenced and the actual reference. E.g.

[
  {
  "category": "DOI",
  "value": "11.1111/abcdef123456789"
  },
  {
  "category": "PMID",
  "value":  "12345678"
  }
]

[floWetzels]

The missing mapping to ISA terms is a good catch indeed. Maybe it makes sense to add the corresponding ISA term to the property description whenever possible. What do you think, @stuzart?

[floWetzels]

Regarding the PubMedID and DOI, this is something that the ARC handles in comments, right? They are not part of ISA, as far as I can see. I like the solution via the identifier field, but should it be part of the profile?

[floWetzels]

Regarding the last bullet point, I think this needs to be specified. I don't know what you mean by that, @HLWeil.

[HLWeil]

Regarding the PubMedID and DOI, this is something that the ARC handles in comments, right? They are not part of ISA, as far as I can see. I like the solution via the identifier field, but should it be part of the profile?

No, these are actually part of the ISA-Model (e.g. see here). So we would just use Identifier and describe the intended usage in the profile?

[stuzart]

I think it would be OK to use identifier in these cases for DOI or Pubmed. It could either be a URL, but if it needs to give more info about the category then it can also be a PropertyMap. The JSONLD example on schema.org shows

"identifier": {
 "@type": "PropertyValue",
   "propertyID": "OCoLC",
   "value":  "889647468"
  },

so I think this could be used if needed, but generally I think just URL would be fine.

[floWetzels]

Agreed, I think the profile and our tools should allow both options.

[floWetzels]

@stuzart Do you agree to add the mapped ISA terms to the descriptions?

[HLWeil]

@floWetzels, you mean mention what ISA-Json properties are covered by which Schema.org profiles?

IMO we really need this somewhere. Alternatively, we could create a mapping table like the one for MIAPPE?

[HLWeil]

Agreed, I think the profile and our tools should allow both options.

I disagree with this, I think we should decide on one option to reduce strain and error-proneness of parsers. Especially sameAs is a bit of an arbitrary mapping.

Although I must say that 'URL' does also make intuitive sense. But then would we also use it generically like identifier or would it mean one specific online resource type like a DOI?

[HLWeil]

@floWetzels @stuzart

[floWetzels]

Agreed, I think the profile and our tools should allow both options.

I disagree with this, I think we should decide on one option to reduce strain and error-proneness of parsers. Especially sameAs is a bit of an arbitrary mapping.

Although I must say that 'URL' does also make intuitive sense. But then would we also use it generically like identifier or would it mean one specific online resource type like a DOI?

What do you mean by sameAs? It was never mentioned before.
I think @stuzart and I agreed on using identifier for things like DOIs, ORCIDs, PubMedIDs, etc. What we meant by allowing both options is that you can either use a simple URL in the identifier property (which is perfectly valid for DOIs or ORCIDs, don't know how PubMedIDs work) or a PropertyValue, which encodes the type of ID and a number/key.
In my opinion, this is a very reasonable use case and we should allow it, but I might be overlooking something.

[HLWeil]

The sameAs was already part of the profile prior to this PR. It was used to denote the PubmedID, I think. Therefore it should be thrown out if we switch to the identifier approach.

[HLWeil]

What we meant by allowing both options is that you can either use a simple URL in the identifier property (which is perfectly valid for DOIs or ORCIDs, don't know how PubMedIDs work) or a PropertyValue, which encodes the type of ID and a number/key. In my opinion, this is a very reasonable use case and we should allow it, but I might be overlooking something.

Oh okay I see, yeah that definitely makes sense.

[floWetzels]

I will close this issue now, as the remaining mapping documentation has its own issue now: #20