Artikel mit Tag Registry:

  • The Paris Northern Spring Interop

    Interior of a large tent

    The plenaries of the Paris interop take place in a tent, because Paris Observatory doesn't have a room large enough given the number of participants. Well, this certainly gets the prize of the most original venue of all the Interops I've been at.

    About every six month, the people making the standards for the Virtual Observatory meet to sort out the next things we need to tackle, to show off what we've done, and to meet each other in person, which sometimes is what it takes to take some excessive heat out of a debate or two. We've talked about Interops before. And now it's time for this (northern) spring's Interop, which is taking place in Paris (Program).

    This time I thought I'd see if there's any chance I can copy the pattern I'm enjoying at Skyweek now and then: A live blog, where I'll extend the post as I go. If that's a plan that can fly remains to be seen, as I'll give seven talks until Friday, and there's a plethora of side meetings and other things requiring my attention.

    Anyway, the first agenda item is a meeting of the TCG, the Technical Coordination Group, which is made up of the chairs and vice-chairs of the IVOA's working groups (I'm in there as the vice chair of the semantics WG). We'll review how the standards under review progress, sanction (or perhaps defer) errata, and generally look at issues of general VO interest.

    Update (2019-05-12, 10:50): Oh dang, my VOResource 1.1 Erratum 1 hasn't quite made it. You see, it's about authentication, i.e., restricting service access, which, in a federated, interoperating system is trickier than you would think, and quite a few discussions on that will happen during this Interop. So, the TCG has just decided to only consider it passed if nothing happens this week that would kill it. To give you an idea of other things we've talked about: Obscore 1.1 Erratum 1 and SODA 1.0 Erratum 1 both try to fix problems with UCD annoation (i.e., a rough idea what it is) not directly related to the standards themselves but intended to help when service results are consumed outside of the standard context, and RegTAP 1.0 Erratum 1 fixes an example in the standard regulating registry discovery that didn't properly take into account my old nemesis, case-insensitivity of IVOA identifiers. So, yay!, at least one of my Errata made the TCG review.

    Update (2019-05-12, 12:15): Yay! After some years of back and forth, the TCG has finally endorsed my Discovering Data Collections note. This is another example of the class of text you don't really notice. It's supposed to let you, for instance, type in a table name into TOPCAT and then figure out at which TAP service to query it. You say: I can already do that! I say: Yeah, but only because I'm running a non-standard service, which I'd like to cease at some point.

    Update (2019-05-12, 15:55): The TCG meeting slowly draws to an end. This second half was, in particular, concerned with reports from Working and Interest Groups; this is, essentially, an interactive version of the roadmaps, where the various chairs say what they'd like to do in the six month following an Interop. The one from after College Park (VO insiders live by Interops, named by the towns they're in) you could read at 2018 B Roadmap in the IVOA Wiki – but really, as of next Friday, you'd rather look at what's going be cooked up here (which will be at 2019 A Roadmap).

    Update (2019-05-12, 16:30) It's now Exec, i.e., the governing body of the VO, consisting of the principal investigators (or, bosses), of the national VO projects (I'm just sitting in for my boss, really). This has, for instance, the final say on what gets to be a standard and what doesn't. This is, of course, a bit more formal than the hands-on debates going on in the TCG, so I get to look around a bit in the meeting room. And what a meeting room they have here at Paris observatory. Behind me there's a copy of Louis XIV's most famous portrait (and for a reason: Louis XIV had the main part of the building we're in built), along the walls around me are the portraits of the former directors of Paris observatory (among them names all mathematicians or astronomers know: Laplace, Delaunay, Lalande, the Cassinis, and so on), and above me, in the meeting room's dome, there's an allegoric image of a Venus transit that I can't link here lest schools block this important outreach site. What a pity we'll have to move into a tent when everyone else comes in tomorrow...

    Update (2019-05-13, 9:11) The logistics speech is being given by Baptiste Cecconi, who's just given the carbon footprint of this meeting – 155 tons of CO2 for travel alone, or 1.2 tons per person. That, as he points out, is about what would be sustainable per year. Well, they're trying to make amends as far as possible. We'll have vegetarian-only food today (good for me), and locally grown food as far as possible. Also, the conference freebie is a reusable cup so people won't produce endless amounts of waste plastic cups. I have to say I'm impressed.

    Update (2019-05-13, 9:43): One important function of these meetings is that when software authors and users sit together, it's much easier to fix things. And, first success for me this time around: The LAMOST services at the data center of the Czech academy of sciences do fast positional searches now; you'll find them by looking for LAMOST in TOPCAT's SSAP window, in Aladin 10, in Splat, or really whereever clients let you do discovery of spectral services in the VO.

    Update (2019-05-13, 10:59): Next up: “Charge to the Working Groups”. That's when the various working group chairs give lightning talks on what's going to happen in their sessions and try to pull as many people as they can. Meanwhile, in the coffee break, I've had the next little success: With the people involved, we've worked out a good way to fix a Registry problem briefly described by “two publishing registries claim the same authority” (it's always nice to pretend I'm in Star Trek) – indeed, we'll only need a single deletion at a single point. Given the potential fallout of such a problem, that's very satisfying.

    Update (2019-05-13, 14:07): While the IG/WG chairs presented their plans, the Ghost of Le Verrier (or was it just the wind?) occasionally haunted the tent, which gave off dreadful noises. And after the session, I quickly ported the build infrastructure for the future EPN-TAP specification (SVN for nerds; previously in this blog for the rest of you) to python 3. Le Verrier was quiet during that time, so I'm sure the guy who led the way to the discovery of Uranus approved.

    Update (2019-05-13, 14:29): Mark SubbaRao from Chicago's Adler Planetarium is giving a plenary talk (in other places, this might be called a ``keynote'') on Planetaria and the VO. And he makes the point that there's 150 million people visiting a plenetarium each year, which, he claims, is a kind of outreach opportunity that no other science has. I'd not bet on that last statement given all the natural history museums, exploratoria, maker faires and the like, but still: That the existence of planetaria says something about the relationship of the public with astronomy is an insight I just had.

    Update (2019-05-13, 15:07): So, you think you just sit back and enjoy a colourful talk, and then suddenly there's work in there. Specifially, there's a standard called AVM designed to annotate astronomical images to show them in the right place on a planetarium dome (ok, FITS WCS can do that as well) and furnish it with other metadata useful in outreach and education. As Registry and Semantics enthusiast, I immediately clicked on the AVM link at the foot of http://www.data2dome.org and was greeted by something pretty close to a standard IVOA document header. Except it declares itself as an “IVOA draft”; such a document category doesn't really exist. Even if it did, after around 10 years (there are conflicting date specs in the document) a document shouldn't be a “draft” any more. If it's survived that long and is still used, it deserves to be some sort of proper document, I think. So, I took the liberty of cold-contacting one of the authors. Let's see where that goes.

    Update (2019-05-13, 16:29): We've just learned about the standardisation process at IPDA (that's a bit like the IVOA, just for planetary data), and interestingly, people are voting there on their standards – this is against the IVOA practice of requiring consensus. Our argument has always been that a standard only makes sense if all interested parties adopt it and thus have to at least not veto it. I wonder if these different approaches have to do with the different demographics: within the IPDA, there are far fewer players (space agencies, really) with much clearer imbalances (e.g., between NASA and the space agency of the UAE). Hm. I couldn't say how these would impact our arguments for requiring consensus...

    Update (2019-05-13, 17:11): Isn't that nice? In the session of the solar system interest group, Eleonora Alei is just reporting on her merged catalog of explanets – which is nice in itself, but what's pleasant for me is to learn she got to make this because of the skills she learned at the ASTERICS school in Strasbourg last November. You see, I was one of the tutors there!

    Update (2019-05-14, 8:50): Next up is the first Registry session, with a talk on how to get the information on all our fine VO services into B2Find, a Registry-like thing for the Eurpean Open Science Cloud as its highlight. I'll also present my findings on what we (as the VO) have gotten wrong when we used “capabilities” do describe things, and also progress on VODataService 1.2; this latter thing is, as far as users are concerned, mainly about finally enabling registry searches by space, time, and spectral coverage.

    Update (2019-05-14, 14:11): So, I did run into overtime a bit with my talks, which mostly is a good sign in Interops, because it indicates there's discussion, which again indicates interest in the topic at hand. The rest of the morning I spent trying to work out how we can map the VO Registry (i.e., the set of metadata records about our services) into b2find in a way that it's actually useful. I guess we – that's Claudia from b2find, Theresa as Registry chair, and me – made good progress on this, perhaps not the least because of the atmosphere of the meeting: In the sun in the beautiful garden of Paris observatory. And now: Data Models I.

    Update (2019-05-14, 14:51): Whoops – Steve just mentions in his talk on the Planetary Data System that there's ISO 14721, a reference model for an Open Archival Information System. Since I run such an archive, I'm a bit embarrassed to admit I've never heard of that standard. The question, of course, being if this has the same relationship to actually running an Archive as ISO 9001 has to “quality” (Scott Adams once famously said something to the effect of: if you've not worked with ISO 9001, you probably don't know what it is. If you have worked with ISO 9001, you certainly don't know what it is).

    Update (2019-05-15, 9:30): I've already given my first talk today: TIMESYS and TOPOCENTER, on a quick way to deal with the problem of adjusting for light travel times when people have not reduced the times they give to one of the standard reference positions. There's more things close to my heart in this session: MOCs in Space and Time, which might become relevant for the Registry [up-update: and, wow, of quick searches against planetary or asteroid orbits. Gasp]; you see, MOCs are rather compact representations of (so far only spatial) coverages, and the space MOCs are already in use for the Registry in the rr.stc_spatial table on the TAP service at http://dc.g-vo.org/tap. The temporal part of STC-based discovery is just intervals at this point, which probably is good enough – but who knows? And I'm also curious about Dave's thoughts on the registration of VOEvents, which takes up something I've reviewed ages ago and that went dormant then – which was somewhat of a pity, because there's to this day no way to find active VOEvent streams.

    Update (2019-05-15, 11:16): Now I'm in Education (Program), where I'll talk about the tutorial I made for the Astroplate workshop I blogged about the other day. Hendrik is just reporting about the PyVO course I've wanted to properly publish for a long time. Pity I'll probably miss Giulia's Virtual Reality experiences because I'll have to head over to DAL later...

    Update (2019-05-15, 14:18): After another Exec session over lunch I ran over to a session somewhat flamboyantly called “TAP-fostered Authentication in the Server-Client scenario“. This is about enabling running access-controlled services, which I'm not really a fan of; but then I figure if people can use VO tools to access their proprietary data, chances are better that that data will eventually be usable from everyone's VO tools. Data dumped behind custom-written web pages will much less likely be freed in the end, or so I believe. Anyway, I'm now in the game of figuring out how to do this, and I'm giving the (current) Registry perspective. The main part of the session, however, will be free discussion, a time-honored and valuable tradition at Interops.

    Update (2019-05-16, 9:00): I'm now in the Theory session, where people deal with simulated data and such things (rather than, as you might guess, with the theory of publishing and/or processing data). The main reason I'm here is that theory was an early adopter of vocabularies. Due to my new(ish) role in the semantics WG, I'll have to worry about this, because things changed a bit since they started (I'll talk about that later today) – and also, some of their vocabularies – for instance, object types – are of general interest and shouldn't probably be theory-only. Let's see how far my charm goes...

    Update (2019-05-16, 12:20): I was doing a bit of back-and-forth between a DAL session (in which, among other things, my colleague Jon gave a talk on a machine-readable grammar for ADQL and Dave tells us how ADQL 2.1 goes on (previously on this blog), and a code sprint the astropy folks have next to the conference, where we've been discussing pyVO's future (remember pyVO? See the update for yesterday 11:16 if not).

    Update (2019-05-16, 14:27): Again, in-session running: I gave a quick talk on how we'll finally get to do data collection-based discovery (rather than service-based, as we do now; lecture notes) and then walked through the garden of Paris observatory to the semantics session, where I joined while people were still discussing the age-old problem of enumerating the observatories, space-probes, and instruments in the world (an endeavour that, very frankly, scares me a tiny bit because of its enormous size). After talks on the use of vocabularies in CAOM2 (Pat) and theory (Emeric), I'll then do my first formal action in the semantics WG: I'll disclose my plans for specifying how the IVOA should do vocabulary work in the future.

    Update (2019-05-16, 17:56): So, the afternoon, between my talks in Registry II and Semantics, planning for the Semantics roadmap (this is something where WG chairs say what they're planning until the next Interop; more on this, I guess, tomorrow), talking with the theory people about how their vocabularies will better integrate with the wider VO, and passing on pyVO to core astropy folks, was a bit too busy for live-blogging. I conclude with a “splinter” on the development of Datalink. This is pure discussion without a formal talk, which, frankly, often is the most useful format for things we do at Interops, and there's almost 20 people here. In contrast to yesterday's after-show splinter (which was on integration of the VO Registry with b2find), I'm just a participant here. Phewy.

    Update (2019-05-17, 8:52): We're going to start the last act of Interops, where the working group chairs report on the progress made during the interop. That, at the time of writing, only three WGs already have their slide on it shows that that's always a bit of a real-time affair – understandibly, because the last bargains and agreements are being worked out as I write. This time around, though, there's a variation to that theme: The astropy hackathon that ran in parallel to the Interop will also present its findings, and I particularly rejoice because they're taking over pyVO development. That's excellent news because Stefan, who's curated pyVO for the last couple of years from Heidelberg, has moved on and so pyVO might have orphaned. That's what I call a happy end.

    Update (2019-05-17, 13:01): So, after reviews and a kind good-bye speech by the Exec chair Mark Allen – which included quite a bit well-deserved applause for the organisers of the meeting –, the official part is over. Of course, I still have a last side-meeting: planning for what we're going to do within ESCAPE, a project linking astronomy with the European Open Science Cloud. But that's not going to be more than an hour. Good-bye.

  • A Grey Eminence of a Standard

    [Screenshot: graphs and numbers]

    Examples for extra metadata: extended column descriptions on the web pages accompanying the ARI-Gaia TAP service.

    Last friday, I've uploaded a first working draft of VODataService 1.2 to the IVOA documents repository. That's the first major step in updating a standard, and it's an invitation to everyone to have a look and comment.

    Foof, you might say, what do I care? I've not even heard of that standard.

    Well, but you've probably used it. VODataService is (among several other things) the standard that governs how a TAP service tells clients (TOPCAT, say) what tables it has and what's inside of them. So, if you see in TOPCAT that there is a column named ang_error with a unit of deg, a UCD of stat.error;pos and the meaning “1 σ confidence radius of the position”, that most likely came in a document standardised by VODataService.

    The question of what (TAP) services can tell clients about their table set is one major open point: Do we want additional metadata there? This article's image, for inspiration, shows a screenshot of extended metadata Grégory delivers to browsers on his ARI-Gaia service; among this are minima, maxima, means, standard deviations, quartiles, and fill factors (i.e., how many of the columns are NULL). He even shows histograms of the values' distributions and HEALPix maps showing how (the means of) the values vary on the sky. Another example of extended metadata could be footnotes as you will find them on many of my resources' reference URLs (example; footnotes are, unsurprisingly, near the foot of that page).

    We could define interoperable means to communicate information like this. The question is: does the added value justify the complication in implementation? This is where it would be great if you weighed in, in particular if you are a “mere” TAP user: Are there any such pieces of metadata you've always wanted to see in your TAP interfaces? Oh, and metadata of course can also be added to tables rather than columns. The current draft already lets services communicate the number of rows in each table – is there more “simple”, table-specific metadata of this sort?

    VODataService furthermore deals with several other topics; for instance, the STC in the registry business I've blogged about in February is going to be standardised here (update on this: spectral coverage is no longer in wavelength but in energy). Other changes are rather more technical in nature, like several new resource types that will improve the discovery of tables and other such resources, or a careful adjustment of some features to keep them in line with TAP evolution.

    But don't let the technicalities scare you away – just have a peek, and if you have thoughts on any of the VODataService topics: I'm just a mail away.

  • Space and Time not lost on the Registry

    Histogram: observation dates of an image service

    A histogram of times for which the Palomar-Leiden service has images: That's temporal service coverage right there.

    If you are an astronomer and you've ever tried looking for data in the Virtual Observatory Registry, chances are you have wondered “Why can't I enter my position here?” Or perhaps “So, I'm looking for images in [NIII] – where would I go?”

    Both of these are examples for the use of Space-Time Coordinates (STC) in data discovery – yes, spectral coordinates count as STC, too, and I could make an argument for it. But this post is about something else: None of this has worked in the Registry up to now.

    It's time to mend this blatant omission. To take the next steps, after a bit of discussion on some of the IVOA's mailing lists, I have posted an IVOA note proposing exactly those last Thursday. It is, perhaps with a bit of over-confidence, called A Roadmap for Space-Time Discovery in the VO Registry. And I'd much appreciate feedback, in particular if you are a VO user and have ideas on what you'd like to do with such a facility.

    In this post, I'd like to give a very quick run-down on what is in it for (1) VO users, (2) service operators in general, and (3) service operators who happen to run DaCHS.

    First, users. We already are pretty good on spatial coverage (for about 13000 of almost 20000 resources), so it might be worth experimenting with that. For now, the corresponding table is only available on the RegTAP mirror at http://dc.g-vo.org/tap. There, you can try queries like:

    select ivoid from
    rr.table_column
    natural join rr.stc_spatial
    where
      1=contains(gavo_simbadpoint('HDF'), coverage)
      and ucd like 'phot.flux;em.radio%'
    

    to find – in this case – services that have radio fluxes in the area of the Hubble Deep Field. If these lines scare you or you don't know what to do with the stupid ivoids, check the previous post on this blog – it explains a bit more about RegTAP and why you might care.

    Similarly cool things will, hopefully, some day be possible in spectrum and time. For instance, if you were interested in SII fluxes in the crab nebula in the early sixties, you could, some day, write:

    SELECT ivoid FROM
    rr.stc_temporal
    NATURAL JOIN rr.stc_spectral
    NATURAL JOIN rr.stc_spatial
    WHERE
      1=CONTAINS(gavo_simbadpoint('M1'), coverage)
      AND 1=ivo_interval_overlaps(
        6.69e-7, 6.75e-7,
        wavelength_start, wavelength_end)
      AND 1=ivo_interval_overlaps(
        36900, 38800,
        time_start, time_end)
    

    As you can see, the spectral coordiate will, following (admittedly broken) VO convention, be given in meters of vacuum wavelength, and time in MJD. In particular the thing with the wavelength isn't quite settled yet – personally, I'd much rather have energy there. For one, it's independent of the embedding medium, but much more excitingly, it even remains somewhat sensible when you go to non-electromagnetic messengers.

    A pattern I'm trying to establish is the use of the user-defined function ivo_interval_overlaps, also defined in the Note. This is intended to allow robust query patterns in the presence of two intrinsically interval-valued things: The service's coverage and the part of the spectrum you're interested in, say. With the proposed pattern, either of these can degenerate to a single point and things still work. Things only break when both the service and you figure that “Aw, Hα is just 656.3 nm” and one of you omits a digit or adds one.

    But that's academic at this point, because really few resources define their coverage in time and and spectrum. Try it yourself:

    SELECT COUNT(*) FROM (
      SELECT DISTINCT ivoid FROM rr.stc_temporal) AS q
    

    (the subquery with the DISTINCT is necessary because a single resource can have multiple rows for time and spectrum when there's multiple distinct intervals – think observation campaigns). If this gives you more than a few dozen rows when you read this, I strongly suspect it's no longer 2018.

    To improve this situation, the service operators need to provide the information on the coverage in their resource records. Indeed, the registry schemas already have the notion of a coverage, and the Note, in its core, simply proposes to add three elements to the coverage element of VODataService 1.1. Two of these new elements – the coverage in time and space – are simple floating-point intervals and can be repeated in order to allow non-contiguous coverage. The third element, the spatial coverage, uses a nifty data structure called a MOC, which expands to “HEALPix Multi-Order Coverage map” and is the main reason why I claim we can now pull off STC in the Registry: MOCs let databases and other programs easily and quickly manipulate areas on the sphere. Without MOCs, that's a pain.

    So, if you have registry records somewhere, please add the elements as soon as you can – if you don't know how to make a MOC: CDS' Aladin is there to help. In the end, your coverage elements should look somewhat like this:

    <coverage>
      <spatial>3/336,338,450-451,651-652,659,662-663
        4/1816,1818-1819,1822-1823,1829,1840-1841</spatial>
      <temporal>37190 37250</temporal>
      <temporal>54776 54802</temporal>
      <spectral>3.3e-07 6.6e-07</spectral>
      <spectral>2.0e-05 3.5e-06</spectral>
      <waveband>Optical</waveband>
      <waveband>Infrared</waveband>
    </coverage>
    

    The waveband elements are remainders from VODataService 1.1. They are still in use (prominently, for one, in SPLAT), and it's certainly still a good idea to keep giving them for the forseeable future. You can also see how you would represent multiple observing campaigns and different spectral ranges.

    Finally, if you're running DaCHS and you're using it to generate registry records (and there's almost no excuse for not doing so), you can simply write a coverage element into your RD starting with DaCHS 1.2 (or, if you run betas, 1.1.1, which is already available). You'll find lots of examples at the usual place. As a relatively interesting example, the resource descriptor of plts. It has this:

      <updater spaceTable="data" spectralTable="data" mocOrder="4"/>
      <spectral>3.3e-07 6.6e-07</spectral>
      <temporal>37190 37250</temporal>
      <temporal>38776 38802</temporal>
      <temporal>41022 41107</temporal>
      <temporal>41387 41409</temporal>
      <temporal>41936 41979</temporal>
      <temporal>43416 43454</temporal>
      <spatial>3/282,410 4/40,323,326,329,332,387,390,396,648-650,1083,1085,1087,1101-1103,1123,1125,1132-1134,1136,1138-1139,1144,1146-1147,1173-1175,1216-1217,1220,1223,1229,1231,1235-1236,1238,1240,1597,1599,1614,1634,1636,1728,1730,1737,1739-1740,1765-1766,1784,1786,2803,2807,2809,2812</spatial>
    </coverage>
    

    This particular service archives plate scans from the Palomar-Leiden Trojan surveys; these were looking for Trojan asteroids (of Jupiter) using the Palomar 122 cm Schmidt and were conducted in several shortish campaigns between 1960 and 1977 (incidentally, if you're looking for things near the Ecliptic, this stuff might still hold valuable insights for you). Because the fill factor for the whole time period is rather small, I manually extracted the time coverage; for that, I ran select dateobs from plts.data via TAP and made the histogram plot above. Zooming in a bit, I read off the limits in TOPCAT's coordinate display.

    The other coverages, however, were put in automatically by DaCHS. That's what the updater element does: for each axis, you can say where DaCHS should look, and it will then fill in the appropriate data from what it guesses gives the relevant coordiantes – that's straightforward for standard tables like the ones behind SSAP and SIAP services (or obscore tables, for that matter), perhaps a bit more involved otherwise. To say “just do it for all axis”, give the updater a single sourceTable attribute.

    Finally, in this case I'm overriding mocOrder, the order down to which DaCHS tries to resolve spatial features. I'm doing this here because in determining the coverage of image services DaCHS right now only considers the centers of the images, and that's severely underestimating the coverage here, where the data products are the beautiful large Schmidt plates. Hence, I'm lowering the resolution from the default 6 (about one degree linearly) to still give some approximation to the actual data coverage. We'll fix the underlying deficit as soon as pgsphere, the postgres extension which is actually dealing with all the MOCs, has support for turning circles and polygons into MOCs.

    When you have defined an updater, just run dachs limits q.rd, and DaCHS will carefully (preserving your indentation) re-write the RD to contain what DaCHS has worked out from your table (but careful: it will overwrite what was previously there; so, make sure you only ask DaCHS to only deal with axes you're not dealing with manually).

    If you feel like writing code discovering holes in the intervals, ideally already in the database: that would be great, because the tighter the intervals defined, the fewer false positives people will have in data discovery.

    The take-away for DaCHS operators is:

    1. Add STC coverage to your resources as soon as you've updated to DaCHS 1.2

    2. If you don't have to have the tightest coverage declaration conceivable, all you have to do to have that is add:

      <coverage>
        <updater sourceTable="my_table"/>
      </coverage>
      

      to your RD (where my_table is the id of your service's “main” table) and then run dachs limits q.rd

    3. For special effects and further information, see Coverage Metadata in the DaCHS reference documentation

    4. If you have a nice postgres function that splits a simple coverage interval up so the filling factor of a set of new intervals increases (or know a nice, database-compatible algorithm to do so) – please let me know.

  • Register your stuff with purx!

    TOPCAT Screenshot

    If you open the TAP dialog of TOPCAT, what you see is Registry content.

    The VO Registry lets people find astronomical resources (which is jargon for “dataset, service, or stuff“). Currently, most of its users don't even notice they're using the Registry, as when TOPCAT just magically lists what TAP services are available (image above) – but there are also interfaces that let you directly interact with the registry, for instance GAVO's WIRR service or ESAVO's Registry Search.

    Arguably, the usefulness of the Registry scales with its completeness. With sufficient completeness, the domain-specific, structured metadata will also make it interesting for generic discovery of astronomical data; in a quip, looking for UCDs in google will never work quite well – and without that, it's hard to find things with queries like „radio fluxes of early-type stars”.

    Either way: If you have a data set or a service dealing with astronomy, it'd be great if you could register it. To do this, so far you either had to set up a publishing registry, which is nontrivial even if you have a software that natively speaks a protocol called OAI-PMH (DaCHS does, but most other publishing suites don't) or you could use one of two web interfaces to define your resource (notes for a talk on this I gave in 2016).

    Neither of these options is really attractive if you publish only a few resources (so the overhead of running a publishing registry looks excessive) that change now and then (so using a web browser to update the resource records again and again is tedious). Therefore, GAVO has developed purx, the publishing registry proxy. We've officially announced it during the recent Southern Spring Interop in Santiago de Chile (Program), and the lecture notes for that talk are probably a good introduction to what this is about.

    If you're running VO services and have not registered them so far, you probably want to read both these notes and the service documentation. If, on the other hand, you just have a web-published directory of files or a browser-based service, you probably can skip even that. Just grab a sample record (use the one for a simple browser service in both cases) and adapt it to what's fitting for your website. Then put the resulting file online somewhere and paste the URL of that location on purx' enrollment service. In case you're uncertain about some of the terms in the record, perhaps our crib sheet for metadata we ask our data providers for will be helpful.

    There's really no excuse any more for not being in the Registry!

  • GAVO at the Northern Spring Interop

    A cake celebrating IVOA 2002-2017

    15 Years of IVOA: The birthday cake our Shanghai hosts prepared for us.

    Every half year, VO enthusiasts from all over the world gather for an “Interoperability conference”, or Interop for short. The latest such event, the Shanghai Interop 2017, ended Friday a week ago. It has been a “long” one again after the short southern spring Interop in Trieste last year (featured in this blog).

    As usual, it was a week of many discussions and much consensus-building. In this post, I'd like to mention a few of the GAVO-related contributions; links typcially go to slides or lecture notes PDFs.

    On the Registry side of things, we're currently (among many other things) briding the gap between DOIs and the Registry in VOResource 1.1, and we invited registry providers to take up the new features, as well as proposing how to update RegTAP (which is used to actually query the Registry) to cope with the new metadata.

    Also in Registry, our efforts of almost a decade to properly support registering tables and similar data collections bore fruit (Britain's Mark Taylor reported on his experiences taking up our current proposal), and the fairly spectacular new Aladin V10 (presented by the CDS' Pierre Fernique, who showed off what I'm tempted to call a “visual registry interface”) urgently needs what we've developed over the years.

    We furthermore reported on new steps to finally let people search the registry using Space-Time constraints (spoiler: the tech is almost there, registry records need lots of work).

    Spatial searches in the registries are one thing enabled by storing and searching for MOCs in relational databases, as was reported by Markus Nullmeier over in an Applications session. The setting may already tell you that these MOCs (Multi Order Coverages, a healpix-based way of representing fairly arbitrary areas on the sky) have applications far beyond Registry.

    Also in Apps, Ole reported on progress in packaging VO applications for easy and reliable installation, in this case for Debian and derivatives. Finally for Apps, Margarida reported on getting lines and line lists into the spectral analysis package SPLAT: Implementation of SLAP and VAMDC interfaces in SPLAT-VO.

    In the wider area of data access protocols and underlying data models, we contributed to Marco's talk on the long-overdue facelifting for the VO's bedrock, Simple Cone Search (Keeping SCS up-to-date within DAL landscape) – the fact that there's an installed base of 15000 of such services may let you guess that we need to tread lightly here. On the bleeding-edge side of things, we presented our current ideas on how, eventually, several data models, data modelling as such and the annotation of data according to these data models might play together in publishing time domain data with DACHS (previously featured on this blog in a slightly less technical way).

    We also talked about education and outreach. Hendrik reported on our ADQL course and how it helps future astronomers learn dealing efficiently with even very large datasets. Hendrik's long-lasting dedication to these topics did not go unpunished at this interop: since the Exec meeting on the Interop Wednesday he is vice-chairing the education interest group of the IVOA. Back in the session I also mused a bit about what metadata changes are needed to make the VO tutorial collection VOTT more useful.

    It is a particular pleasure for me to mention that the IVOA has a new interest group: “Solar System”. Regular readers of the blog will have noticed that I have a particularly soft spot in my heart for that crowd, and so I gave a short overview over how DaCHS is used among them, too.

    And that's just the official programme. Much more fixing, designing, and discussion went on between sessions or in the evenings. The latter, of course, included some decidedly less technical aspects. Including, as pictured above, a nice birthday cake for the IVOA, as it is now 15 year since the first Interop meeting in January 2002.

« Page 2 / 2