We now have duplicated resources between ENPKG and JLW. On my side I have to take decisions about what to keep from ENPKG and what to ignore, or replace, or re-implement. Clearly, the LCMS part of ENPKG is a great improvement and I will adopt it. The rest is a little bit more complicated. Here below my ongoing reflexions:
In the whole RDF dataset at Zenodo, the RDF triples are clearly serving two different purposes:
1) Some RDF triples are produced by the scripts hosted here and are meant to be reusable on other LCMS datasets from MassIVE, if I understand correctly.
2) The rest of the RDF triples were produced with the purpose of creating a demonstrator for the paper. These includes TPH activities, PFcode, ChEMBL, links, ...
It might be beneficial to reflect this by using different prefixes, e.g. keeping "enpkg" for (1) and introducing "enpkgdemo" for (2):
Because "enpkg" and "enpkgdemo" are defined in the same domain name, this distinction will not cause difficulties for the website. Another solution for the demonstrator would be to use the prefix http://example.com (ex:) which is just meant for this.
You are going to focus on maintaining ENPKG after the paper is accepted and move to the next (funded) application, forgetting the actual "demo" part. Keep it simple.
We now have duplicated resources between ENPKG and JLW. On my side I have to take decisions about what to keep from ENPKG and what to ignore, or replace, or re-implement. Clearly, the LCMS part of ENPKG is a great improvement and I will adopt it. The rest is a little bit more complicated. Here below my ongoing reflexions:
In the whole RDF dataset at Zenodo, the RDF triples are clearly serving two different purposes:
1) Some RDF triples are produced by the scripts hosted here and are meant to be reusable on other LCMS datasets from MassIVE, if I understand correctly. 2) The rest of the RDF triples were produced with the purpose of creating a demonstrator for the paper. These includes TPH activities, PFcode, ChEMBL, links, ...
It might be beneficial to reflect this by using different prefixes, e.g. keeping "enpkg" for (1) and introducing "enpkgdemo" for (2):
Because "enpkg" and "enpkgdemo" are defined in the same domain name, this distinction will not cause difficulties for the website. Another solution for the demonstrator would be to use the prefix http://example.com (ex:) which is just meant for this.
You are going to focus on maintaining ENPKG after the paper is accepted and move to the next (funded) application, forgetting the actual "demo" part. Keep it simple.