Adding links

content/deployers/intro_to_vo_concepts.md

@@ -42,10 +42,10 @@ A suite of IVOA protocols specify basic access methods for different types of da
 
 ## Resources and Registries
 
-The two key standards are [Resource Identifier](https://www.ivoa.net/documents/IVOAIdentifiers/) which defines how to uniquely specify a resource, and [Resource Metadata](https://www.ivoa.net/documents/RM/) which lists the items necessary to describe a resource. Information about resources is collected in resource registries, which can then act as the yellow pages of the VO. Note that there is no unique centralised registry approved by some authority. In principle, anybody can set up a registry; but to do so, you need to do it in a standardised way. First, [VOResource](https://www.ivoa.net/documents/VOResource/) specifies an XML encoding standard for recording the standard metadata for a resource entry. This is kept quite generic; there is then a series of "Registry Extension" standards which specify the extra information needed for specific types of resource - for example [VODataService](https://www.ivoa.net/documents/VODataService/), "Application Reg Ext" and so on. Next, "Registry Interface" describes the standardised way in which applications should communicate with registries. This follows a model in which there are two kinds of registries - searchable registries, which applications will query, and publishing registries, where resource providers place their information. There are standard methods for one registry to harvest from another - so the searchable registries can keep up to date, and so publishing registries don't need to be complete, or worry about having a search interface. If you want to know of all the Registries that exist, the IVOA maintains a "Registry of Registries".
+The two key standards are [Resource Identifier](https://www.ivoa.net/documents/IVOAIdentifiers/) which defines how to uniquely specify a resource, and [Resource Metadata](https://www.ivoa.net/documents/RM/) which lists the items necessary to describe a resource. Information about resources is collected in resource registries, which can then act as the yellow pages of the VO. Note that there is no unique centralised registry approved by some authority. In principle, anybody can set up a registry; but to do so, you need to do it in a standardised way. First, [VOResource](https://www.ivoa.net/documents/VOResource/) specifies an XML encoding standard for recording the standard metadata for a resource entry. This is kept quite generic; there is then a series of "Registry Extension" standards which specify the extra information needed for specific types of resource - for example [VODataService](https://www.ivoa.net/documents/VODataService/), "Application Reg Ext" and so on. Next, [Registry Interface](https://ivoa.net/documents/RegistryInterface/) describes the standardised way in which applications should communicate with registries. This follows a model in which there are two kinds of registries - searchable registries, which applications will query, and publishing registries, where resource providers place their information. There are standard methods for one registry to harvest from another - so the searchable registries can keep up to date, and so publishing registries don't need to be complete, or worry about having a search interface. If you want to know of all the Registries that exist, the IVOA maintains a [Registry of Registries](https://ivoa.net/documents/Notes/RegistryOfRegistries/index.html).
 
 ## Data Modelling and Semantics
-A simple cone search service might allow a user to search for catalogue rows where the source RA and Dec is within a certain range, but the returned data will typically contain many other columns with many strange names. To make sense of these the user would need to separately consult the documentation on the providers web page. But if the returned data follows some standard structure, and uses standard ways of specifying what kind of quantity is in a column, a lot more can be done automatically by a good application. Working towards this ideal, the IVOA is developing a suite of standard data models, such as "Phot DM" for photometry data, "Obs core DM" for databases describing collections of observational data, "VO Event" for describing transient events such as supernovae and gamma-ray bursts, and so on. These make use of standard "Utypes" which specify how to define the elements of a data model, the "STC" standard which specifies how to refer to Space and Time Co-ordinates, and "Units" for specifying the units of a quantity as a simple string. There is also a controlled vocabulary known as "Universal Content Descriptors (UCDs)". For example, a column with the name "ALPHA" could be anything, but if it has the associated UCD "POS.EQ.RA" then you know it is a Right Ascension, in the equatorial system. There could be several columns in a table with the same UCD however - for example, the RA of the source, and the RA of the detector frame it was found on. To specify which is which you need a full data model. The UCD system is a fixed (but evolving) dictionary. A more general standard called "Vocabularies", which follows the W3C RDF and SKOS standards, allows for more flexible definition of vocabularies, and so will allow different groups to define and maintain their own vocabularies, but in a way that others can use.
+A simple cone search service might allow a user to search for catalogue rows where the source RA and Dec is within a certain range, but the returned data will typically contain many other columns with many strange names. To make sense of these the user would need to separately consult the documentation on the providers web page. But if the returned data follows some standard structure, and uses standard ways of specifying what kind of quantity is in a column, a lot more can be done automatically by a good application. Working towards this ideal, the IVOA is developing a suite of standard data models, such as [Phot DM](https://ivoa.net/documents/PHOTDM/) for photometry data, [ObsCore DM](https://ivoa.net/documents/ObsCore/) for databases describing collections of observational data, [VOEvent](https://ivoa.net/documents/VOEvent/) for describing transient events such as supernovae and gamma-ray bursts, and so on. These make use of standard "Utypes" which specify how to define the elements of a data model, the STC standard which specifies how to refer to [Space and Time Co-ordinates](https://ivoa.net/Documents/latest/STC.html), and [VOUnits](https://ivoa.net/documents/VOUnits/) for specifying the units of a quantity as a simple string. There is also a controlled vocabulary known as [Universal Content Descriptors (UCDs)](https://ivoa.net/Documents/latest/UCD.html). For example, a column with the name "ALPHA" could be anything, but if it has the associated UCD "POS.EQ.RA" then you know it is a Right Ascension, in the equatorial system. There could be several columns in a table with the same UCD however - for example, the RA of the source, and the RA of the detector frame it was found on. To specify which is which you need a full data model. The UCD system is a fixed (but evolving) dictionary. A more general standard called [Vocabularies](https://ivoa.net/Documents/Vocabularies/), which follows the W3C RDF and SKOS standards, allows for more flexible definition of vocabularies, and so will allow different groups to define and maintain their own vocabularies, but in a way that others can use.
 
 ## Sharing: Distributed Computational Infrastructure