From b3a47bc7c05861bf05c58595653707b57d2ea9e9 Mon Sep 17 00:00:00 2001 From: youphendriks Date: Mon, 16 Sep 2024 14:05:42 +0200 Subject: [PATCH] Delete testservice and groovy json LAX parser --- createSitemap.groovy | 2 +- docs/createCatalog.groovy | 3 +- docs/createIndex.groovy | 3 +- docs/service/createMarkdown.groovy | 2 +- docs/service/testservice.json | 433 ----------------------------- 5 files changed, 4 insertions(+), 439 deletions(-) delete mode 100644 docs/service/testservice.json diff --git a/createSitemap.groovy b/createSitemap.groovy index 689495a..9ee88cc 100644 --- a/createSitemap.groovy +++ b/createSitemap.groovy @@ -27,7 +27,7 @@ list = list.sort() list.each { file -> fileContents = file.text //def data = new JsonSlurper().parseText(fileContents) - def data = new JsonSlurper().parseText(fileContents).setType(JsonParserType.LAX) + def data = new JsonSlurper().parseText(fileContents) println """ https://cloud.vhp4safety.nl/service/${data.id}.html 1.00 diff --git a/docs/createCatalog.groovy b/docs/createCatalog.groovy index 562bebd..19ecb87 100644 --- a/docs/createCatalog.groovy +++ b/docs/createCatalog.groovy @@ -38,8 +38,7 @@ println "\n" */ list.each { file -> fileContents = file.text - def data = new JsonSlurper().parseText(fileContents).setType(JsonParserType.LAX) - //def data = new JsonSlurper().parseText(fileContents) + def data = new JsonSlurper().parseText(fileContents) logo = "" if (data.screenshot) logo = "![${data.service} logo](https://raw.githubusercontent.com/VHP4Safety/cloud/main/docs/service/${data.screenshot} \"Click on the image to go to the service\")\n" println """------------------------------------------------------------------------------- diff --git a/docs/createIndex.groovy b/docs/createIndex.groovy index fa04299..273847e 100644 --- a/docs/createIndex.groovy +++ b/docs/createIndex.groovy @@ -49,8 +49,7 @@ list = list.sort() list.each { file -> fileContents = file.text - //def data = new JsonSlurper().parseText(fileContents) - def data = new JsonSlurper().parseText(fileContents).setType(JsonParserType.LAX) + def data = new JsonSlurper().parseText(fileContents) logo = "" if (data.instance && (data.instance.type == "VHP4Safety") && (data.instance["vhp-platform"] == "Development")) { if (data.screenshot) logo = "\"screenshot" diff --git a/docs/service/createMarkdown.groovy b/docs/service/createMarkdown.groovy index 9229692..f0ee56d 100644 --- a/docs/service/createMarkdown.groovy +++ b/docs/service/createMarkdown.groovy @@ -46,7 +46,7 @@ def processRich(line, data, selector, expanding) { args.each { dataFile -> if (dataFile != "template.json") { fileContents = new File(dataFile).text - def data = new JsonSlurper().parseText(fileContents).setType(JsonParserType.LAX) + def data = new JsonSlurper().parseText(fileContents) outputFile = new File(data.id + ".md") outputFile.text = "" diff --git a/docs/service/testservice.json b/docs/service/testservice.json deleted file mode 100644 index 539e43a..0000000 --- a/docs/service/testservice.json +++ /dev/null @@ -1,433 +0,0 @@ - -// This is a template for JSON files that can provide a standard way to add - -/* Please create a new JSON file to add a new service to the catalog. While -creating that file based on this template, please consider the comments -below to fill the items to have a standard representation of services. -Please feel free to raise an issue or give feedback for the template in the // issues section (https://github.com/VHP4Safety/cloud/issues) of this -repository.*/ - -// [?OC] I believe we should set a list of minimum required information. For -// instance, if there is no id, service or description, how do we create an -// item in the catalog? I think, there should be at least these three items, -// and maybe an URL, whether to an external or internal address. - -{ - // An id for the JSON file, please fill the id below with the same name as - // the JSON file that you are creating for the service. Please use only small - // case letters and do not use spaces between words. - "id": "", - - // The (stylized) name of the service which will be shown as the name of the - // service in the catalog. - "service": "", - - // A description for the service. We currently use a short, generally, a - // single-sentence description. - "description": "", - - // The name of the file for the service logo. Please use the same name as the - // service id. - // [?OC] Do we really need this. We can check if there is a logo file in the - // createMarkdown file and if there's, it will put the logo. Although, then - // different file types (whether the logo file has a jpeg, png, or another - // extension) might be a problem. - "screenshot": "", - - // An URL to the service. - // [?OC] Do we mean a general URL to the service, or the URL to the instance - // running on our servers. Based on that there is an "instance" section below - // I think this can be a general, external link such as - // https://www.bridgedb.org/ or https://aopwiki.org/. Otherwise, there might - // be a redundancy in the service information. - "url": "", - - // The DOI of the document (article, preprint, etc.) where information - // regarding the service can be found. - // [?OC] Do we force people to give a DOI? What if there is a document that - // does not have a DOI? - "doi": "", - - // Information regarding the service's instance that is running on our - // servers. - "instance": { - - // [?OC] What exactly is type, actually? I thought this indicates the type - // of the API like REST or SPARQL? But, I am probably wrong. Or, maybe it - // can indicate whether the service is an online interactive tool, or a - // database, or something else. - "type": "", - - // The indication for whether the service is running on the development or - // production platform. - "vhp-platform": "", - - // The URL to the service instance running on our servers. - "url": "", - - // The license of the service specified by its creators/maintainers. - // [?OC] There are different ways to indicate the license. The common - // licences are easy to add here (we can even give a link somehow) but - // some services use a custom license to which they have a link. In such - // cases, we need to provide the link here instead of just the name of the - // licence. It should be possible, but we need to make a decision. - "license": "", - - // The version of the service that is listed in the catalog. - "version": "", - - // The link to the source material of the service. - "source": "", - - // The link to the repository where service's Docker container is stored. - "docker": "", - - // Technology Readiness Level. For details, please see: - // https://en.wikipedia.org/wiki/Technology_readiness_level - // [?OC] Do we have someone who knows and can explain this rating system. - // Personally, I do not know how to use this scale. - "TRL": "" - }, - - // Information regarding the provider/maintainer of the service. - "provider": { - "contact": { - // The name of a person from the organization that provide the service. - "name": "", - // The email of the person whose name given above. - "email": "" - }, - - // An URL to the organization that provide the service. - "url": "", - // The name of the organization that provide the service. - "name": "" - }, - - // Information regarding the remote use of the service. - "access": { - // The type of API, if available. - // [?OC] I think we need a link to the API, as well. - "API": "", - // Whether the API requires authenication. - "login": "", - // Information regarding other types of implementations of the service, - // such as an R package or a Python module. - // [?OC] I think we need some clarification here. Are these basic - // information like, yes/no, or do we need to give a link to the packages? - // I think the latter would be better. - "packages": { - "R": "", - "Python": "" - } - }, - - // Information regarding an available demo documentation about the service. - // [?OC] Do we mean a tutorial documentation that will be provided on our - // docs-repo? If so, I think we should make it clear here because this will - // be filled by us. - "intro": { - // The title of the intro on the VHP4Safety platform. - "title": "", - // A link to the intro on the VHP4Safety platform. - "url": "" - }, - "demo": { - // The title of the demo. - "title": "", - // A link to the demo. - "url": "" - }, - "workflow": { - // The title of the VHP4Safety workflow where it is being used. TODO: should be one or more. - "title": "", - // A link to the workflow. - "url": "", - }, - - // Information regarding sources available on ELIXIR. - // [?OC] Is this a correct explanation for the information we ask here? - // [?OC] Also, is the information below supposed to be a link? If so, I think - // we should make it clear here. - "ELIXIR": { - // The keyword for the link to the source on bio.tools. - "biotools": "", - // The keyword for link to the source on TeSS. - "tess": "", - // the DOI for the entry on FAIRsharing.org - "fairsharing": "" - }, - - // Other information sources - "Other": { - // Wikipedia page - "wikipedia": "", - // Dutch Research Software Directory - "rsd": "" - }, - - // Information about NAM validation stage as described in the 2017 RIVM report (https://www.rivm.nl/documenten/landschap-3v-methoden-risicobeoordeling-chemische-stoffen) - // Answer wether the service has completed the stage using yes or no. - "NAM-validation": { - // Stage 1: Research & development. - "NAM-stage-1": "", - // Stage 2: Validation. - "NAM-stage-2": "", - // Stage 3: Evaluation. - "NAM-stage-3": "", - // Stage 4: Acceptation. - "NAM-stage-4": "", - // Stage 5: Implementation. - "NAM-stage-5": "" - }, - - // Is the service usable by one, or more, of the VHP persona's? - // Answer yes or no. - // TODO: Replace placeholders (eg. "persona-1") with persona's and descriptions of persona. These are yet to be created. - "VHP-persona": { - // VHP persona 1 - "persona-1": "", - // VHP persona 2 - "persona-2": "", - // VHP persona 3 - "persona-3": "" - }, - - // Is the service relevant for answering one, or more, of the regulatory questions as read on (https://docs.vhp4safety.nl/en/latest/introduction/case_studies_and_regulatory_questions.html)? - // Question 1: Kidney Disease: Disease scenario to study disease and pharmacovigilance. - // Question 2: Life Course Pesticide Exposure and Neurodegenerative Disease: Life course exposure scenario to study life course exposure and neurodegenerative disease. - // Question 3: Thyroid Mediated Developmental Neurotoxicity: Age and sex scenario to study health effects discriminated by age and sex on thyroid mediated neurodevelopment. - "regulatory-question": { - // 1a: What is a safe dose for cisplatin/tacrolimus in patients with respect to chronic kidney disease? - "1a": "", - // 1b: How can we take into account variability in activity/expression of P-gp in patients that underwent a transplantation? - "1b": "", - // 2a: Can compound X cause Parkinson’s Disease? - "2a": "", - // 2b: Can we identify groups at extra risk to develop Parkinson’s Disease after exposure to compound X? - "2b": "", - // 3a: What information about a substance do we need to give an advice to women in their early pregnancy to decide whether the substance can be used? - "3a": "", - // 3b: Does compound X influence the thyroid-mediated brain development in the fetus resulting in cognitive impairment in children? - "3b": "" - }, - - -} - -// This is a template for JSON files that can provide a standard way to add -// new services to the cloud catalog, maintained with this repository. - -// Please create a new JSON file to add a new service to the catalog. While -// creating that file based on this template, please consider the comments -// below to fill the items to have a standard representation of services. -// Please feel free to raise an issue or give feedback for the template in the // issues section (https://github.com/VHP4Safety/cloud/issues) of this -// repository. - -// [?OC] I believe we should set a list of minimum required information. For -// instance, if there is no id, service or description, how do we create an -// item in the catalog? I think, there should be at least these three items, -// and maybe an URL, whether to an external or internal address. - -{ - // An id for the JSON file, please fill the id below with the same name as - // the JSON file that you are creating for the service. Please use only small - // case letters and do not use spaces between words. - "id": "", - - // The (stylized) name of the service which will be shown as the name of the - // service in the catalog. - "service": "", - - // A description for the service. We currently use a short, generally, a - // single-sentence description. - "description": "", - - // The name of the file for the service logo. Please use the same name as the - // service id. - // [?OC] Do we really need this. We can check if there is a logo file in the - // createMarkdown file and if there's, it will put the logo. Although, then - // different file types (whether the logo file has a jpeg, png, or another - // extension) might be a problem. - "screenshot": "", - - // An URL to the service. - // [?OC] Do we mean a general URL to the service, or the URL to the instance - // running on our servers. Based on that there is an "instance" section below - // I think this can be a general, external link such as - // https://www.bridgedb.org/ or https://aopwiki.org/. Otherwise, there might - // be a redundancy in the service information. - "url": "", - - // The DOI of the document (article, preprint, etc.) where information - // regarding the service can be found. - // [?OC] Do we force people to give a DOI? What if there is a document that - // does not have a DOI? - "doi": "", - - // Information regarding the service's instance that is running on our - // servers. - "instance": { - - // [?OC] What exactly is type, actually? I thought this indicates the type - // of the API like REST or SPARQL? But, I am probably wrong. Or, maybe it - // can indicate whether the service is an online interactive tool, or a - // database, or something else. - "type": "", - - // The indication for whether the service is running on the development or - // production platform. - "vhp-platform": "", - - // The URL to the service instance running on our servers. - "url": "", - - // The license of the service specified by its creators/maintainers. - // [?OC] There are different ways to indicate the license. The common - // licences are easy to add here (we can even give a link somehow) but - // some services use a custom license to which they have a link. In such - // cases, we need to provide the link here instead of just the name of the - // licence. It should be possible, but we need to make a decision. - "license": "", - - // The version of the service that is listed in the catalog. - "version": "", - - // The link to the source material of the service. - "source": "", - - // The link to the repository where service's Docker container is stored. - "docker": "", - - // Technology Readiness Level. For details, please see: - // https://en.wikipedia.org/wiki/Technology_readiness_level - // [?OC] Do we have someone who knows and can explain this rating system. - // Personally, I do not know how to use this scale. - "TRL": "" - }, - - // Information regarding the provider/maintainer of the service. - "provider": { - "contact": { - // The name of a person from the organization that provide the service. - "name": "", - // The email of the person whose name given above. - "email": "" - }, - - // An URL to the organization that provide the service. - "url": "", - // The name of the organization that provide the service. - "name": "" - }, - - // Information regarding the remote use of the service. - "access": { - // The type of API, if available. - // [?OC] I think we need a link to the API, as well. - "API": "", - // Whether the API requires authenication. - "login": "", - // Information regarding other types of implementations of the service, - // such as an R package or a Python module. - // [?OC] I think we need some clarification here. Are these basic - // information like, yes/no, or do we need to give a link to the packages? - // I think the latter would be better. - "packages": { - "R": "", - "Python": "" - } - }, - - // Information regarding an available demo documentation about the service. - // [?OC] Do we mean a tutorial documentation that will be provided on our - // docs-repo? If so, I think we should make it clear here because this will - // be filled by us. - "intro": { - // The title of the intro on the VHP4Safety platform. - "title": "", - // A link to the intro on the VHP4Safety platform. - "url": "" - }, - "demo": { - // The title of the demo. - "title": "", - // A link to the demo. - "url": "" - }, - "workflow": { - // The title of the VHP4Safety workflow where it is being used. TODO: should be one or more. - "title": "", - // A link to the workflow. - "url": "", - }, - - // Information regarding sources available on ELIXIR. - // [?OC] Is this a correct explanation for the information we ask here? - // [?OC] Also, is the information below supposed to be a link? If so, I think - // we should make it clear here. - "ELIXIR": { - // The keyword for the link to the source on bio.tools. - "biotools": "", - // The keyword for link to the source on TeSS. - "tess": "", - // the DOI for the entry on FAIRsharing.org - "fairsharing": "" - }, - - // Other information sources - "Other": { - // Wikipedia page - "wikipedia": "", - // Dutch Research Software Directory - "rsd": "" - }, - - // Information about NAM validation stage as described in the 2017 RIVM report (https://www.rivm.nl/documenten/landschap-3v-methoden-risicobeoordeling-chemische-stoffen) - // Answer wether the service has completed the stage using yes or no. - "NAM-validation": { - // Stage 1: Research & development. - "NAM-stage-1": "", - // Stage 2: Validation. - "NAM-stage-2": "", - // Stage 3: Evaluation. - "NAM-stage-3": "", - // Stage 4: Acceptation. - "NAM-stage-4": "", - // Stage 5: Implementation. - "NAM-stage-5": "" - }, - - // Is the service usable by one, or more, of the VHP persona's? - // Answer yes or no. - // TODO: Replace placeholders (eg. "persona-1") with persona's and descriptions of persona. These are yet to be created. - "VHP-persona": { - // VHP persona 1 - "persona-1": "", - // VHP persona 2 - "persona-2": "", - // VHP persona 3 - "persona-3": "" - }, - - // Is the service relevant for answering one, or more, of the regulatory questions as read on (https://docs.vhp4safety.nl/en/latest/introduction/case_studies_and_regulatory_questions.html)? - // Question 1: Kidney Disease: Disease scenario to study disease and pharmacovigilance. - // Question 2: Life Course Pesticide Exposure and Neurodegenerative Disease: Life course exposure scenario to study life course exposure and neurodegenerative disease. - // Question 3: Thyroid Mediated Developmental Neurotoxicity: Age and sex scenario to study health effects discriminated by age and sex on thyroid mediated neurodevelopment. - "regulatory-question": { - // 1a: What is a safe dose for cisplatin/tacrolimus in patients with respect to chronic kidney disease? - "1a": "", - // 1b: How can we take into account variability in activity/expression of P-gp in patients that underwent a transplantation? - "1b": "", - // 2a: Can compound X cause Parkinson’s Disease? - "2a": "", - // 2b: Can we identify groups at extra risk to develop Parkinson’s Disease after exposure to compound X? - "2b": "", - // 3a: What information about a substance do we need to give an advice to women in their early pregnancy to decide whether the substance can be used? - "3a": "", - // 3b: Does compound X influence the thyroid-mediated brain development in the fetus resulting in cognitive impairment in children? - "3b": "" - }, - - -}