diff --git a/README.md b/README.md index c8d4901..4f614c8 100644 --- a/README.md +++ b/README.md @@ -1,21 +1,74 @@ -## Dataverse External Vocabulary Management +# Dataverse External Vocabulary Management -Dataverse supports the use of third-party vocabulary services through a generic external vocabulary support mechanism, service-specific scripts, and a custom json configuration setting that allows specification of how fields in Dataverse metadatablocks are to be associated with specific services and vocabularies. +Dataverse supports the use of third-party vocabulary and persistent identifier (PID) services through a generic external vocabulary support mechanism that allows service-specific scripts, and field-specific json configurations added via a Dataverse setting that allows specification of how fields in Dataverse metadatablocks are to be associated with specific services and vocabularies. -This repository contains several usable scripts and example materials that demonstrate how to configure Dataverse to leverage them. +For example, instead of a plain text type in, one could select a term from multiple vocabularies: + +Select a vocabulary + + + +and then a term + + + +and have them displayed as a link to the remote site defining the term: + + + +Or, with [additions planned for Dataverse 6.4](https://github.com/IQSS/dataverse/pull/10712), one could replace the four author related fields with selectors for [ORCID](https://orcid.org) (people) and [ROR](https://ror.org) (organizations) + + + +which would display as entries with icons that link to the definition pages. + + + +and can still support entering info for people/organizations who do not have ORCID or ROR entries. + +Display can also be graphical, as in displaying [Local Contexts](https://localcontexts.org/) Notices and Labels + + + +## Repository Contents + +This repository contains scripts and example materials that demonstrate how to configure Dataverse to leverage them. They are a mixture of initial proofs-of-concept, demonstrations of alternative approaches, and some that are potentially mature enough for production use (although the latter often require later versions of Dataverse which have extensions/bug fixes for the underlying mechanism. Documentation in the /examples subdirectory provides additional details for specific scripts and configuration for specific fields. + +It also contains a [JSON Schema that can be used to validate configuration files](https://github.com/gdcc/dataverse-external-vocab-support/blob/main/examples/config/demo/CVocConf.schema.json). + +## Scripts in Production + +The following scripts/config files are being used in production (or testing) at one or more Dataverse Sites + +* **ORCID and ROR for Dataset authors** - see [https://github.com/gdcc/dataverse-external-vocab-support/examples/authorIDandAffilationUsingORCIDandROR.md](https://github.com/gdcc/dataverse-external-vocab-support/examples/authorIDandAffilationUsingORCIDandROR.md) + + +* **Integration with [https://localcontexts.org](https://localcontexts.org)** (on [https://demo.dataverse.org](https://demo.dataverse.org) using the LocalContexts Sandbox) - see [https://github.com/gdcc/dataverse-external-vocab-support/tree/main/packages/local_contexts](https://github.com/gdcc/dataverse-external-vocab-support/tree/main/packages/local_contexts) + +## Deployment + +In general there are three steps to add interaction with a vocabulary or PID service to Dataverse: + +* Identify the metadata field to be enhanced. This can be a field in an existing block, or one in a custom block that you install (there are some custom blocks in this repo for various scripts). As with any custom block, you must [install it in Dataverse](https://guides.dataverse.org/en/latest/admin/metadatacustomization.html#metadata-block-setup), enable the use of this new block in your Dataverse collection (e.g. Use the Edit/General Information menu item, /Metadata Fields section to add the block/specific fields.) and add any desired terms from the example block to the Browse/Search Facets list (same Edit/General Information menu item) +* Create a configuration file and [submit it as the :CVocConf setting value](https://guides.dataverse.org/en/latest/installation/config.html#cvocconf) for your Dataverse. It is probably easiest to modify the example scripts here. Nominally you would only need to change the metadata field the script will enhance and the URL for the location of the script. You should validate your file against the provided [JSON Schema](https://guides.dataverse.org/en/latest/installation/config.html#cvocconf) to avoid errors that can break the Dataverse page display. +* Deploy the script(s) to a local location that matches the URL you chose in the config file. It is possible to access the scripts from the github.io URLs used in the example config files here, but this is not recommended as we are not yet versioning the scripts and assuring that the version in the repository will not change. + +To deploy scripts to multiple fields, you need to add one section (JSON Object) per field/script combo to the array in your config file. + +## How It All Works + +The basic idea of the Dataverse External Vocabulary mechanism is to simplify adding and displaying controlled terms and PIDs as metadata. As far as Dataverse is concerned, all that is happening is that a term or PID URI is being entered into a text field and Dataverse then stores and displays the term/PID URI. The interesting part is that a JavaScript is taking over Dataverse's text input and text display to instead provide support such as a type-ahead lookup from a vocabulary/PID service and, on the diplay side, displaying the human-readable name of associated with the term/PID, and potentially additional metadata about the term/PID, rather than the raw URI. + +The scripts know which fields to manage based on some invisible data-cvoc-* attributes Dataverse adds to the page's HTML. Dataverse has a flexible configuration mechanism to allow admins to specify which fields should be associated with which scripts, but, in other repositories, these associations could be static. For example, [this simple static example page](examples/staticOrcidAndRorExample.html) shows the ORCID and ROR scripts associated with two input and two display fields. You can look at the page source to see the additional attributes in the HTML that make this work. + +There's more of course. When a repository already has separate subfields for names and identifiers, scripts can be written to fill in both. If the underlying vocabulary/PID service supports multiple vocabularies, or has an advanced search mechanism, the scipts can be written to let you select which vocabulary to use or provide an advanced search interface. If there's a field where you want to be able to handle free text as well as controlled terms/PIDs, scripts can support that as well. Dataverse also includes a mechanism to allow metadata about the terms/PIDs to be captured, making it possible to provide internationalization for search (i.e. allowing search in your language for a term), include organization acronyms in exported metadata formats, etc. Fortunately, most of this complexity is handled by script/config example developers and Dataverse admins just need to select which ones to install. + +For further details, see [James D. Myers, & Vyacheslav Tykhonov. (2023). A Plug-in Approach to Controlled Vocabulary Support in Dataverse.](https://doi.org/10.5281/zenodo.8133723) +[](https://doi.org/10.5281/zenodo.8133723) -Example Setup: -To enable external voabulary support on the example metadata block provided you need to: -* Install the custom metadata block -* Update your solr schema to include the custom fields -* Set the :CVocConf setting - use the /examples/config/cvoc-conf.json as the value -* Enable the use of this new block in your test Dataverse collection (e.g. Use the Edit/General Information menu item, /Metadata Fields section to add the block/specific fields.) -* Add any desired terms from the example block to the Browse/Search Facets list (same Edit/General Information menu item) -Only the third step is specific to enabling external vocabulary support. The others are just the standard steps for installing a new metadata block in Dataverse. -If you create your own :CVocConf setting value (i.e. to manage other fields), you can use the /examples/config/CVocConf.schema.json file to validate your syntax. ### Packages diff --git a/examples/affiliation.md b/examples/affiliation.md index 259fb7e..91624d6 100644 --- a/examples/affiliation.md +++ b/examples/affiliation.md @@ -2,7 +2,7 @@ The affiliation example illustrates a lookup in ROR.org for the author affiliati Two files comprise this example: -- examples/config/affiliation.json : the configuration file that needs to be uploaded in the :CVocConf setting +- examples/config/demo/affiliation.json : the configuration file that needs to be uploaded in the :CVocConf setting - scripts/affiliation.js : the Javascript file that modifies standard Dataverse behaviour diff --git a/examples/authorIDandAffilationUsingORCIDandROR.md b/examples/authorIDandAffilationUsingORCIDandROR.md new file mode 100644 index 0000000..ff52838 --- /dev/null +++ b/examples/authorIDandAffilationUsingORCIDandROR.md @@ -0,0 +1,35 @@ +## Dataverse Author Field Example + +This example manages the author field (the name, idType, Identifier, and affiliation child fields), providing (ORCID)[https://orcid/org] and (ROR)[https://ror.org] lookup while also allowing free text entries (for entities that don't have these identifiers) and manual entry of alternate identifiers for authors. + +This example requires the changes being added to Dataverse in (PR #10712)[https://github.com/IQSS/dataverse/pull/10712] expected in v6.4. + +This example requires several files: + +- examples/config/authorsOrcidAndRor.json : the configuration file that needs to be uploaded in the :CVocConf setting + +- scripts/people.js : the Javascript file that provides ORCID support, +- scripts/ror.js : the Javascript file that provides ROR support, +- scripts/cvocutil.js : a Javascript file with common methods used by both scripts, + +(These scripts also use jquery and select2 which are already included in Dataverse). + +### How to install: + +Minimal: + +- load the authorsOrcidAndRor.json file in the :CVocConf setting using the [Dataverse API](https://guides.dataverse.org/en/latest/installation/config.html?highlight=cvocconf). e.g. using curl: `curl -X PUT --upload-file authorsOrcidAndRor.json http://localhost:8080/api/admin/settings/:CVocConf`. + +- Alternately, add the two JSON Objects in the top level JSON Array in authorsOrcidAndRor.json to you existing :CVocConf setting file (for installations that are deploying other CVoc scripts already) + +- refresh your browser page. That's it. You should see displays like those shown in this repo's README file. + +Production: +- Also copy the three script files to a local website and adjust the URLs in authorsOrcidAndRor.json that invoke them to use your local copies. This assures that changes in this repository will not automatically be used on your site. +- Adapt your CSS styling to improve how well the interfaces created by the script match your custom style. + +### Interesting Features +- Searches can be done by person/organization name, but can also use other metadata, e.g. a person's email address or an originization in their employment or education history in their ORCID profile, or the acronym of an organization (entry must be at least 3 letters) +- Once an ORCID or ROR has been used in a given browser, that entry will appear at the top of the list as soon as it is one of the results returned from the service. This makes it easier to find a commonly used entry when there are similar ones. +- The people.js script understands that Dataverse has separate idType and Identifier fields for authors. When a free text entry is added as a name (i.e. there is no associated ORCID), the script will restore the idType and Identifier subfields so that an Identifier of some other type that Dataverse supports can be entered. +- Both ORCID and ROR icons are displayed with entries. They link to the person's/organization's page at ORCID/ROR. diff --git a/examples/authors.md b/examples/authors.md index 5484571..68efe7a 100644 --- a/examples/authors.md +++ b/examples/authors.md @@ -1,31 +1,31 @@ -The authors example uses the external vocabularies mechanism to implement a simple lookup and copy-and-paste functionality for the authors fields (name, affiliation, indentification scheme and number). It is different from the other examples as it does not store URLs to the external vocabulary, but instead copies the data directly into the dataverse metadata fields. The link with the vocabulary URI is therefore not persisted. +The authors example uses the external vocabularies mechanism to implement a simple lookup and copy-and-paste functionality for the authors fields (name, affiliation, identification scheme and number). It is different from the other examples as it does not store URLs to the external vocabulary, but instead copies the data directly into the dataverse metadata fields. The link with the vocabulary URI is therefore not persisted. There are several reasons why we implemented it like this: -- we did not want to expose the personel data unprotected to the public internet. By copying the data instead of the URL, we can open the vocabulary only to the IP ranges that need access to dataset metadata editing, which for our institution is esentially on-premis or via VPN. The vocabulary server is no longer needed when the dataset metadata is published and accessed publicly. +- we did not want to expose the personal data unprotected to the public internet. By copying the data instead of the URL, we can open the vocabulary only to the IP ranges that need access to dataset metadata editing, which for our institution is essentially on-premis or via VPN. The vocabulary server is no longer needed when the dataset metadata is published and accessed publicly. -- the data in the vocabulary will rarely change, it will only be expanded. The risk of author information getting outdated is very low. And even if so, it is likely that it would be better to leave the old metadata alone. +- the data in the vocabulary will rarely change, it will only be expanded. The risk of author information getting out-dated is very low. And even if so, it is likely that it would be better to leave the old metadata alone. -- we implemented it as a prototype for other metadata fields where the vocabulary data will most certainly change and we do not want these changes to percollate into the metadata of existing datasets. One such field is our faculty or department field. Departments splitting and merging do occur fairly regularly and we want the metadata to reflect the organisational entity as it was when the dataset was created. While this can be achieved in external vocabularies with deprecated entries, the extra complexity of maintaining the external vocabulary for a fairly simple list is not worth it. We will just change the list as we go and leave the existing data alone. +- we implemented it as a prototype for other metadata fields where the vocabulary data will most certainly change and we do not want these changes to percolate into the metadata of existing datasets. One such field is our faculty or department field. Departments splitting and merging do occur fairly regularly and we want the metadata to reflect the organiational entity as it was when the dataset was created. While this can be achieved in external vocabularies with deprecated entries, the extra complexity of maintaining the external vocabulary for a fairly simple list is not worth it. We will just change the list as we go and leave the existing data alone. To illustrate the example for our authors lookup there are 2 files provided: -- examples/config/authors.json : the configuration file that needs to be uploaded in the :CVocConf setting +- examples/config/demo/authors.json : the configuration file that needs to be uploaded in the :CVocConf setting - scripts/authors.js : the Javascript file that modifies standard Dataverse behaviour The standard authors compound fields are used, so there is no need to modify the default citation metadata block. -Note that this is a trimmed-down version of de code that we use in production. Our production version can be found in our [github repository](https://github.com/libis/rdm-covoc_server). There you will also find the implementation of a small REST server that performs the search in the background. +Note that this is a trimmed-down version of the code that we use in production. Our production version can be found in our [github repository](https://github.com/libis/rdm-covoc_server). There you will also find the implementation of a small REST server that performs the search in the background. -The JSON configuration file has most fields empty, but as they are all required, they need to be present in the configuration file. The `field-name` and `term-uri-field` have both been set to `authorName`. Only the field `field-name` should be set for this to work, but as I found out the hard way, the external vocabulary code insits that the `term-uri-field` also points to a valid metadata field. Theoretically, this means that the external vocabulary code that looks up values externally could be triggered if an URI is filled in in the `authorName` field, but it is fairly safe to asume that that will not be the case during normal use. +The JSON configuration file has most fields empty, but as they are all required, they need to be present in the configuration file. The `field-name` and `term-uri-field` have both been set to `authorName`. Only the field `field-name` should be set for this to work, but as I found out the hard way, the external vocabulary code insists that the `term-uri-field` also points to a valid metadata field. Theoretically, this means that the external vocabulary code that looks up values externally could be triggered if an URI is filled in in the `authorName` field, but it is fairly safe to assume that that will not be the case during normal use. -The `js-url` field in the configuration file points to the location where the JavaScript file is located. Since we already use an Apache frontend server to enable the Shibboleth logins, we decided to reverse-proxy the JavaScript file there as well. The other fields are emtpy and have no influence on our code. +The `js-url` field in the configuration file points to the location where the JavaScript file is located. Since we already use an Apache frontend server to enable the Shibboleth logins, we decided to reverse-proxy the JavaScript file there as well. The other fields are empty and have no influence on our code. The JavaScript file contains three parts: - first of all code that is triggered each time the page is loaded and each time an author compound field set is added or deleted. That piece of code is responsible for creating the HTML code for a modal dialog box with search box and table with results. It also puts a search button next to each authorName input field that will display the dialog box. -- the `authorsQuery` function performs a call to a server that will search the given string in the database and return the data for the matches found. The code asumes this to be a simeple REST server that returns JSON data. The server itself in our case uses a Solr index to query and retrieve the data. Again, for security reasons we did not want to expose the Solr server directly beyond the server itself, so a simple REST server in front of it sanitizes the queries and protects the Solr index from being abused. +- the `authorsQuery` function performs a call to a server that will search the given string in the database and return the data for the matches found. The code assumes this to be a simple REST server that returns JSON data. The server itself in our case uses a Solr index to query and retrieve the data. Again, for security reasons we did not want to expose the Solr server directly beyond the server itself, so a simple REST server in front of it sanitizes the queries and protects the Solr index from being abused. -- the `importAuthorData` function is triggered when a user selects one of the search results and is responsible for copying the JSON data into the input fields on the dataset metadata form. Most of it is pretty straightforward code looking for the input fields in the form and setting the values, except for the part where the `identifierScheme` has to be filled in. The dropdown box consists of multiple elements that have to be changed in sync and it took a while to figure that out. This is also the weakest point in the code, as translations could modify any displayed text and thus could break the code that relies on the text `ORCID` to be present in the dropdown box. In this case that is something we have full contol of, but be warned when porting this code to other fields. \ No newline at end of file +- the `importAuthorData` function is triggered when a user selects one of the search results and is responsible for copying the JSON data into the input fields on the dataset metadata form. Most of it is pretty straightforward code looking for the input fields in the form and setting the values, except for the part where the `identifierScheme` has to be filled in. The dropdown box consists of multiple elements that have to be changed in sync and it took a while to figure that out. This is also the weakest point in the code, as translations could modify any displayed text and thus could break the code that relies on the text `ORCID` to be present in the dropdown box. In this case that is something we have full control of, but be warned when porting this code to other fields. \ No newline at end of file diff --git a/examples/config/authorsOrcidAndRor.json b/examples/config/authorsOrcidAndRor.json new file mode 100644 index 0000000..7e8caad --- /dev/null +++ b/examples/config/authorsOrcidAndRor.json @@ -0,0 +1,75 @@ +[ + { + "field-name": "authorAffiliation", + "term-uri-field": "authorAffiliation", + "js-url": ["https://qualitativedatarepository.github.io/dataverse-external-vocab-support/scripts/ror.js","https://qualitativedatarepository.github.io/dataverse-external-vocab-support/scripts/cvocutils.js"], + "protocol": "ror", + "retrieval-uri": "https://api.ror.org/organizations/{0}", + "allow-free-text": true, + "prefix": "https://ror.org/", + "managed-fields": {}, + "languages":"en", + "vocabs": { + "rors": { + "uriSpace": "https://ror.org/" + } + }, + "retrieval-filtering": { + "@context": { + "termName": "https://schema.org/name", + "scheme": "http://www.w3.org/2004/02/skos/core#inScheme", + "lang": "@language", + "content": "@value" + }, + "scheme": { + "pattern": "http://www.grid.ac/ontology/" + }, + "termName": { + "pattern": "{0}", + "params": ["/name"] + }, + "@type": { + "pattern": "https://schema.org/Organization" + } + } + }, + { + "field-name": "author", + "term-uri-field": "authorIdentifier", + "js-url": ["https://qualitativedatarepository.github.io/dataverse-external-vocab-support/scripts/people.js","https://qualitativedatarepository.github.io/dataverse-external-vocab-support/scripts/cvocutils.js"], + "protocol": "orcid", + "retrieval-uri": "https://pub.orcid.org/v3.0/{0}/person", + "allow-free-text": true, + "prefix": "https://orcid.org/", + "managed-fields": { + "personName":"authorName", + "idType":"authorIdentifierScheme" + }, + "languages":"en", + "vocabs": { + "orcid": { + "uriSpace": "https://orcid.org/" + } + }, + "retrieval-filtering": { + "@context": { + "personName": "https://schema.org/name", + "scheme": "http://www.w3.org/2004/02/skos/core#inScheme" + }, + "personName": { + "pattern": "{0}, {1}", + "params": ["/name/family-name/value", "/name/given-names/value"] + }, + "@id": { + "pattern": "{0}", + "params": ["@id"] + }, + "scheme": { + "pattern": "ORCID" + }, + "@type": { + "pattern": "https://schema.org/Person" + } + } + } +] diff --git a/examples/config/affiliation.json b/examples/config/demos/affiliation.json similarity index 100% rename from examples/config/affiliation.json rename to examples/config/demos/affiliation.json diff --git a/examples/config/authors.json b/examples/config/demos/authors.json similarity index 100% rename from examples/config/authors.json rename to examples/config/demos/authors.json diff --git a/examples/config/cvoc-conf.json b/examples/config/demos/cvoc-conf.json similarity index 100% rename from examples/config/cvoc-conf.json rename to examples/config/demos/cvoc-conf.json diff --git a/examples/config/cvoc-conf.singlevocab.json b/examples/config/demos/cvoc-conf.singlevocab.json similarity index 100% rename from examples/config/cvoc-conf.singlevocab.json rename to examples/config/demos/cvoc-conf.singlevocab.json diff --git a/examples/config/grantNumberAgencyFundreg.json b/examples/config/demos/grantNumberAgencyFundreg.json similarity index 100% rename from examples/config/grantNumberAgencyFundreg.json rename to examples/config/demos/grantNumberAgencyFundreg.json diff --git a/examples/config/keywordExample.json b/examples/config/demos/keywordExample.json similarity index 100% rename from examples/config/keywordExample.json rename to examples/config/demos/keywordExample.json diff --git a/examples/config/rorAuthAffiliation.json b/examples/config/demos/rorAuthAffiliation.json similarity index 96% rename from examples/config/rorAuthAffiliation.json rename to examples/config/demos/rorAuthAffiliation.json index 7bade9b..80c6c95 100644 --- a/examples/config/rorAuthAffiliation.json +++ b/examples/config/demos/rorAuthAffiliation.json @@ -1,36 +1,36 @@ -[ - { - "field-name": "authorAffiliation", - "term-uri-field": "authorAffiliation", - "js-url": ["/cvoc/js/ror.js","/cvoc/js/cvocutils.js"], - "protocol": "ror", - "retrieval-uri": "https://api.ror.org/organizations/{0}", - "allow-free-text": true, - "prefix": "https://ror.org/", - "managed-fields": {}, - "languages":"", - "vocabs": { - "rors": { - "uriSpace": "https://ror.org/" - } - }, - "retrieval-filtering": { - "@context": { - "termName": "https://schema.org/name", - "scheme": "http://www.w3.org/2004/02/skos/core#inScheme", - "lang": "@language", - "content": "@value" - }, - "scheme": { - "pattern": "http://www.grid.ac/ontology/" - }, - "termName": { - "pattern": "{0}", - "params": ["/name"] - }, - "@type": { - "pattern": "https://schema.org/Organization" - } - } - } +[ + { + "field-name": "authorAffiliation", + "term-uri-field": "authorAffiliation", + "js-url": ["/cvoc/js/ror.js","/cvoc/js/cvocutils.js"], + "protocol": "ror", + "retrieval-uri": "https://api.ror.org/organizations/{0}", + "allow-free-text": true, + "prefix": "https://ror.org/", + "managed-fields": {}, + "languages":"", + "vocabs": { + "rors": { + "uriSpace": "https://ror.org/" + } + }, + "retrieval-filtering": { + "@context": { + "termName": "https://schema.org/name", + "scheme": "http://www.w3.org/2004/02/skos/core#inScheme", + "lang": "@language", + "content": "@value" + }, + "scheme": { + "pattern": "http://www.grid.ac/ontology/" + }, + "termName": { + "pattern": "{0}", + "params": ["/name"] + }, + "@type": { + "pattern": "https://schema.org/Organization" + } + } + } ] \ No newline at end of file diff --git a/examples/config/depositorOrcid.json b/examples/config/depositorOrcid.json new file mode 100644 index 0000000..76fea8b --- /dev/null +++ b/examples/config/depositorOrcid.json @@ -0,0 +1,38 @@ +[ + { + "field-name": "depositor", + "term-uri-field": "depositor", + "js-url": ["https://qualitativedatarepository.github.io/dataverse-external-vocab-support/scripts/people.js","https://qualitativedatarepository.github.io/dataverse-external-vocab-support/scripts/cvocutils.js"], + "protocol": "orcid", + "retrieval-uri": "https://pub.orcid.org/v3.0/{0}/person", + "allow-free-text": true, + "prefix": "https://orcid.org/", + "managed-fields": {}, + "languages":"en", + "vocabs": { + "orcid": { + "uriSpace": "https://orcid.org/" + } + }, + "retrieval-filtering": { + "@context": { + "personName": "https://schema.org/name", + "scheme": "http://www.w3.org/2004/02/skos/core#inScheme" + }, + "personName": { + "pattern": "{0}, {1}", + "params": ["/name/family-name/value", "/name/given-names/value"] + }, + "@id": { + "pattern": "{0}", + "params": ["@id"] + }, + "scheme": { + "pattern": "ORCID" + }, + "@type": { + "pattern": "https://schema.org/Person" + } + } + } +] diff --git a/examples/config/grantNumberAgencyRor.json b/examples/config/grantNumberAgencyRor.json new file mode 100644 index 0000000..078eaed --- /dev/null +++ b/examples/config/grantNumberAgencyRor.json @@ -0,0 +1,36 @@ +[ + { + "field-name": "grantNumberAgency", + "term-uri-field": "grantNumberAgency", + "js-url": ["https://qualitativedatarepository.github.io/dataverse-external-vocab-support/scripts/ror.js","https://qualitativedatarepository.github.io/dataverse-external-vocab-support/scripts/cvocutils.js"], + "protocol": "ror", + "retrieval-uri": "https://api.ror.org/organizations/{0}", + "allow-free-text": true, + "prefix": "https://ror.org/", + "managed-fields": {}, + "languages":"", + "vocabs": { + "ror": { + "uriSpace": "https://ror.org/" + } + }, + "retrieval-filtering": { + "@context": { + "termName": "https://schema.org/name", + "scheme": "http://www.w3.org/2004/02/skos/core#inScheme", + "lang": "@language", + "content": "@value" + }, + "scheme": { + "pattern": "http://www.grid.ac/ontology/" + }, + "termName": { + "pattern": "{0}", + "params": ["/name"] + }, + "@type": { + "pattern": "https://schema.org/Organization" + } + } + } +] \ No newline at end of file diff --git a/examples/staticOrcidAndRorExample.css b/examples/staticOrcidAndRorExample.css new file mode 100644 index 0000000..79a0975 --- /dev/null +++ b/examples/staticOrcidAndRorExample.css @@ -0,0 +1,40 @@ +/* Some minimal styling for the static example. */ +h1 { + text-align: center; +} +#select2-drop{ + width: 400px !important; +} +.select2-container { +min-width: 400px!important; +} +.select2-container .select2-selection--single .select2-selection__rendered { + width:100%; + vertical-align:middle; +} +img { + vertical-align: middle; +} +div { + height:40px; + width:100%; + margin-bottom:30px; +} +.select2-container { + display:block!important; +} +.select2-container .select2-selection--single .select2-selection__rendered { + display:inline-block!important; + max-width:85%; + padding-right:5px!important; +} +.select2-selection__clear, .select2-selection__rendered { + vertical-align: -webkit-baseline-middle; +} +.select2-results ul > li { + font-weight:400; + font-size:14px; +} +.select2-rendered__match { + font-weight:600; +} diff --git a/examples/staticOrcidAndRorExample.html b/examples/staticOrcidAndRorExample.html new file mode 100644 index 0000000..f579d3c --- /dev/null +++ b/examples/staticOrcidAndRorExample.html @@ -0,0 +1,103 @@ + +
+ + + + + + + + + + + + + +