Panel 2 (technical) theme

[kjappelbaum]

• Why don't we already have a solution?

  • Is this a problem that can be solved?
  • What governance worked in other domains?
  • What was feasible in other domains?
    • Charlie mentions that he finds biology simpler: Finite number of genes, etc. Is this really the case?
  • Or do we have a solution that is looking for a problem? Do we actually need all the semantic technologies?

• Is it feasible?

  • Can we have an URI for every chemical? For every instrument?
  • Chemists cannot even agree on the simplest concepts, e.g., what a bond is. How are we then supposed to store a structure?

• Do we need to capture all data?

  • Most of the data is actually trash? Do we really care about this? Do we only amplify noise and waste time by trying to collect every tiny bit of data?

• What do we do with legacy systems and instruments?

  • That are unique and produce data in their own special form
  • Many instruments only save a part of the parameters in the output file. So, the data in these cases is somehow always multimodal. How do we deal with this case?

• What do we actually standardize?

  • Vocabularies?
  • File formats?

• Agility vs. flexibility

  • How do we find the"right" tradeoff?
  • How do we envision the data ending up in some ELN? Chemists won't fill a big form? Will NLP cut it? But then we do not start developing fancy ELNs and can just all have our blogs?
  • We will need to evolve vocabularies and schema -- how do we manage the versions?
    • what happens if there is a schema change will we still work on an experiment?
  • People want to use their analysis tools, how do we track this
  • How do we capture the interpretation of data in a structured way? Do we even do this?
  • When you design a data schema. Let's say for recording XPS spectra you can go into any imaginable detail and this will make potentially enormous mess -- in particular if you forgot to include Auger spectroscopy or something else. How do we start this work? Do we record the most basic things and then add complexity?

• Who is responsible for quality control and how do we do this?

  • We detected an issue with the data? How do we notify potential reusers of the data? Do we send them a notification? Or do the re-users need to check this?

[ml-evs]

All sounds good to me! Couple of comments below (trying to avoid giving my own opinions 🙃)

  * What was feasible in other domains?
    
    * Charlie mentions that he finds biology simpler: Finite number of genes, etc. Is this really the case?
  * Or do we have a solution that is looking for a problem? Do we actually need all the semantic technologies?

I really like this angle --- as an individual researcher/developer willing to invest (time!) in the tech side of this, I still feel there is a huge opportunity cost to "going semantic". Bio/life sciences show that there are great benefits to be had by going down this road, but how does the structure of our domain (quite literally, the microstructure and bonding in materials) affect the topology of resulting knowledge graphs? Are they still useful? Ties in with the named entities discussion in your following point, and with the fuzziness breakout.

* Is it feasible?
  
  * Can we have an URI for every chemical? For every instrument?
  * Chemists cannot even agree on the simplest concepts, e.g., what a bond is. How are we then supposed to store a structure?

* Do we need to capture all data?
  
  * Most of the data is actually trash? Do we really care about this? Do we only amplify noise and waste time by trying to collect every tiny bit of data?

I guess one distinction to make here is between capturing data for all samples/measurements (even ones where e.g. synthesis method yielded impure substance or something) vs. capturing "everything" about each sample (just because it is available), e.g., height above sea-level, partial pressure of radon every second whilst the sample was under storage.

* What do we do with legacy systems and instruments?
  
  * That are unique and produce data in their own special form
  * Many instruments only save a part of the parameters in the output file. So, the data in these cases is somehow always multimodal. How do we deal with this case?

* What do we actually standardize?
  
  * Vocabularies?
  * File formats?

* Agility vs. flexibility
  
  * How do we find the"right" tradeoff?
  * How do we envision the data ending up in some ELN? Chemists won't fill a big form? Will NLP cut it? But then we do not start developing fancy ELNs and can just all have our blogs?
  * We will need to evolve vocabularies and schema -- how do we manage the versions?
    
    * what happens if there is a schema change will we still work on an experiment?

Also, how do we ensure the chemists/materials scientists are empowered by their tooling to create, modify and disseminate their own schemas?

[kjappelbaum]

Thanks for feedback, still a couple of things on my to-read list to flesh this out

[petermr]

What was feasible in other domains?
Charlie mentions that he finds biology simpler: Finite number of genes, etc. Is this really the case?

Biology:
Molecular biology can be codified as gene -> mRNA -> protein and this central dogma has been hugely successful. There was a general realisation in ca 1970 onwards with PIR (Protein Information Resource - Margaret Dayhoff ) for sequences - and PDB for structures that public collected data was a revolutionary research tool. (Without this work we wouldn't be able to understand, let alone challenge, the pandemic). It lead to the Human Genome Project in ca 1999 and now huge numbers of organisms are now sequenced.

This is reductionist bioscience and it works incredibly well, up to a point. It assumes that the general applies to the specific and that the theory applies everywhere. But there are many fuzzy boundaries - evolution, habitat, can't easily be described by identifiers.

Can we have an URI for every chemical?

Where the chemical is well-defined, Yes. We already have several. PubChem, ChEBI, ChEMBL. Open universal URIs have been strongly resisted by the American Chemical Society who tried to close down PubChem and threatened to sue Wikipedia.
Politics/Business is one of the major things holding chemistry back. It's noteworthy that most of the innovation has come from bioscience.

Where the chemical is not well defined (e.g. polymers, mixtures, alloys, etc.) we cannot create a unique ID. We may have to list the components and perhaps put floating points into bins.

For every instrument?
Yes, as long as it has a formal ID it's fairly easy. It's harder when it's customised or merged with other equipment. Here's typical X-ray diffraction from Acta Cryst E 2022:

• Diffractometer | Bruker D8 goniometer with Photon 100 CMOS detector
• Diffractometer | SuperNova, Dual, Cu at home/near, Atlas
• Diffractometer | SuperNova, Single source at offset/far, HyPix3000

We can automate the initial extraction of this data, e.g. get 500 Acta Cryst E papers and tabulate all the descriptions of diffractometers. This can extend to many other instruments. I'd be happy to do a show and tell on this.

This should be extensible to other types of equipment (e.g. NMR, EXAFS, etc.)

Chemists cannot even agree on the simplest concepts, e.g., what a bond is. How are we then supposed to store a structure?

Organic chemistry has "solved" this. For organometallics we have to describe the bits we understand and use a flexible language (e.g. a "bond" in CML can be between different objects (atoms, bonds, groups, regions of "molecules"). Attaching group labels to atoms is very powerful. We may have to agree that ultimately it's the atom coordinates that describe the structure. That's hard in fluxional molecules, so we have to described accurately those bits which are constant.

It may be that only the composition can be stored. And even that may be variable. We may have to use free variables (Ax, B(1-x)) where x is a computable variable. (CML is able to do this)

[kjappelbaum]

re-reading Shirky: Ontology is Overrated -- Categories, Links, and Tags :

• some parts of basic sciences are about breaking rules/categories: how shall a categorization approach work there?
• what are the stable concepts in chemistry?

[kjappelbaum]

re-reading JSON-LD and Why I Hate the Semantic Web | The Beautiful, Tormented Machine:

So, in 2010 we kicked off the JSON-LD work by making it radically open and we fought for that openness every step of the way. Anyone can join the group, anyone can vote on decisions, anyone can join the teleconferences, there are no closed door sessions, and we record the audio of every meeting.

I personally wanted JSON-LD to be compatible with RDF, but that’s about it. You could convert JSON-LD to and from RDF and get something useful, but JSON-LD had a more sane data model where lists were a first-class construct, you had generalized graphs, and you could use JSON-LD using a simple library and standard JSON tooling. To put that in perspective, to work with RDF you typically needed a quad store, a SPARQL engine, and some hefty libraries. Your standard web developer has no interest in that toolchain because it adds more complexity to the solution than is necessary.

• Is it currently too hard for tool developers in chemistry to use semantic tools?

There are many reasons that a working group filled with experts don’t consistently produce great results. For example, many of the participants can be humble about their knowledge so they tend to think that a good chunk of the people that will be using their technology will be just as enlightened. Bad feature ideas can be argued for months and rationalized because smart people, lacking any sort of compelling real world data, are great at debating and rationalizing bad decisions.

. Precious time is spent in groups discussing how we can query all this Big Data that is sure to be published via RDF instead of figuring out a way of making it easy to publish that data on the Web by leveraging common practices in use today. Too much time is spent assuming a future that’s not going to unfold in the way that we expect it to. That’s not to say that TURTLE, SPARQL, and Quad stores don’t have their place, but I always struggle to point to a typical startup that has decided to base their product line on that technology (versus ones that choose MongoDB and JSON on a regular basis).

I like JSON-LD because it’s based on technology that most web developers use today. It helps people solve interesting distributed problems without buying into any grand vision. It helps you get to the “adjacent possible” instead of having to wait for a mirage to solidify.

• connection to Shirky: it is a lot about predicting the future. What is the widely supported tech stack we can use today to build something useful?

[kjappelbaum]

re-reading Whatever Happened to the Semantic Web?

among them the obvious fact that most web users were likely to provide either no
metadata at all or else lots of misleading metadata meant to draw clicks. Even
if users were universally diligent and well-intentioned, in order for the
metadata to be robust and reliable, users would all have to agree on a single
representation for each important concept. Doctorow argued that in some cases a
single representation might not be appropriate, desirable, or fair to all
users.

“Talmudic debates” were so abstract that few of them ever saw widespread adoption. The
few that did, like XML, were “uniformly scourges on the planet, offenses
against hardworking programmers that have pushed out sensible formats (like
JSON) in favor of overly-complicated hairballs with no basis in reality.”

Even the W3C now appears to recognize that few of its Semantic Web standards have been widely adopted and that simpler standards would have been more successful.

, posits that the real problem was the lack of a truly decentralized infrastructure to host the Semantic Web on.16 To host your own website, you need to buy a domain name from ICANN, configure it correctly using DNS, and then pay someone to host your content if you don’t already have a server of your own. We shouldn’t be surprised if the average person finds it easier to enter their information into a giant, corporate data repository. And in a web of giant, corporate data repositories, there are no compelling use cases for Semantic Web technologies.

• how do we envision data sharing? curated repositories? everyone exposes their own dataset?

[kjappelbaum]

stats about how JSON took over XML are here https://twobithistory.org/2017/09/21/the-rise-and-rise-of-json.html

[kjappelbaum]

re-reading “Is the semantic web still a thing?”

The reasons are complex but it basically boils down to: going through all the effort of putting semantic markup with no guarantee of a payoff for yourself was a stupid idea.

The ecology simply hasn’t arisen to make using linked data any easier or more valuable than using anything else (in many contexts and cases, it’s more troublesome and challenging than less abstract formats, in fact).

[kjappelbaum]

It’s hard enough getting people to share data as it is, harder to get them to share it in a particular format, and completely impossible to get them to store it and manage it in a completely new system.

from Aaron Schwarz's unfinished "A Programmable Web"

[ml-evs]

These resources are all great @kjappelbaum, perhaps begging for a section on the awesome interop list?

[kjappelbaum]

yes, will do this. Now only taking quotes to perhaps do something interesting for the panel

[ml-evs]

Aaron Schwarz's unfinished "A Programmable Web" references/is referenced by a lot of these articles, bit longer but quite a nice readable intro to some of these ideas for those unfamiliar, freely available at https://www.morganclaypool.com/doi/abs/10.2200/S00481ED1V01Y201302WBE005

[kjappelbaum]

re-reading metacrap

• People lie: wrong metadata
• People are lazy: do not do a good job in annotation
• People are stupid: spelling/typos/mistakes
• Mission impossible: People are lousy observers of their own behaviors. This might be in particular an issue for reactions/more manual operations
• Schemas aren't neutral: "Any hierarchy of ideas necessarily implies the importance of some axes over others."
• Metrics influence results
• There is more than one way to describe something: ". Requiring everyone to use the same vocabulary to describe their material denudes the cognitive landscape, enforces homogeneity in ideas."

Interesting observation: For google, observational metadata (the links) turned out to be more useful than "real" metadata

[kjappelbaum]

maybe a nice opposing view

Wherever users create hierarchies, e.g. in file systems or within applications, they face the problem that the hierarchy strongly depends on the logic created in it by one or a group of persons. With with increasing complexity it gets more and more difficult, if not impossible to extended it without breaking this logic.
Semantic web technology is a true game changer in that regard. Beside other advantages, it comes with the ability of linking things with any amount of other thing, instead interlinking documents like the world wide web does, or linking a set of things with another set of things, like tables do. Because of using the most fine-granular relation possible, relations do not have to fit into any other logical system, which would have to be designed for a given use case. And semantic data is not required to be stored in a hierarchy, so there is no risk of implementing today a boundary of tomorrow. As a result, the storage pattern is completely nonspecific to any use case, and can be scaled to any size and complexity.

[kjappelbaum]

re-reading FLY ME TO THE MOON

Fundamentally, however, I think the problem comes down to the fact that the Semantic Web technology stack gets a lot of criticism for not hiding the fact that Reality is Hard. The kind of Big Enterprise software sales that get attention promise to hide the details, protect you from complexity, to sweep everything under the rug.
[lots of more good stuff]
What is the alternative? If we abandon these ideas, what do we turn to? The answer after even the briefest consideration is that there is nothing else on the table. No other technology purports to attempt to solve the wide variety of problems that RDF, RDFS, OWL, SPARQL, RDFa, JSON-LD, etc. do.

[dwinston]

This excerpt from "Fly me to the Moon" reminds me of the foreward to Validating RDF Data (2017) by Dan Brickley and Libby Miller:

People think RDF is a pain because it is complicated. The truth is even worse. RDF is painfully simplistic, but it allows you to work with real-world data and problems that are horribly complicated. While you can avoid RDF, it is harder to avoid complicated data and complicated computer problems. RDF brings together data across application boundaries and imposes no discipline on mandatory or expected structures. This can make working with RDF data frustrating. Its schema and ontology languages can help define the meaning of RDF content but, again, can’t express rules about how actual data records should look. The contents of this book are nearly 20 years too late, but better now than never. Recent developments around RDF validation have finally made it easier to record, exchange, and understand rules about validating and otherwise checking RDF data. Who knows what wonders await us in another 20 years.

Dan Brickley, Schema.org and Google
Libby Miller, BBC
July 2017

It seems that the rise of e.g. SHACL has provided a small response to

going through all the effort of putting semantic markup with no guarantee of a payoff for yourself was a stupid idea.

through potential payoff of "validation reuse" through e.g. shared SHACL shapes when one wishes to "close the world" for a given use case.

[petermr]

I'd been planning to relate XML and JSON so this seems a great discussion. Disclaimer: I ran the mailing list for the development of XML, have worked a lot with the RDF/Linked_data people such as Dan Brickley. First and fundamental - this all depends on people and the current wiring of their brains. There was a time before the hierarchical fling system and that hurt people's brains. HTML and XML revolutionised documents and the idea of computable objects. They also promoted democracy - in 1980 much of the technical support was in closed company specifications. We now take this for granted. We have a very complex problem. It's rightly said of code "You cannot hide complexity, you can only move it around". But you can also chunk parts of the problem to agreed labels and then you don't have to explain them. CIF does this. We have concepts such as _unit_cell where the community decides that there is enough agreement that they can use this label and not its contents. Those entering science now (including at school) are fluent in scripting languages and the use of open public knowledge. They use larger chunks than those weaned on FORTRAN. JSON/Python_dictionaries and XML overlap to a large extent. We should be prepared to use either and to interconvert. Each does some things better than the other and vice versa. XML is good at: * namespaces (important for interoperability with other languages) * running text (and especially inline tags (<i>, etc.) * supporting documents creation and publishing (e.g. PubMedCentral) * encouraging domain specific schemas JSON is good at: * reducing clutter * integration with code (e.g. Python dictionaries) * web display (add more to both) Both will last for at least 20 years. RDF/SPARQL is in constant use for large sections of the bioscience community and for Wikidata. I can't see a current alternative. The danger in rejecting these is that you end up with a limited, non-extensible domain-specific language. These persist for decades. Examples include: * MOL/SDF files - limited by the vision of 1980s FORTRAN thinking. * SMILES. tt works for the set of well-behaved covalent organic molecules. * InChI (disclaimer - I was actively involved in its development). Attempts to extend SMILES and InChI (reactions, mixtures) are very limited in scope. They have no extensibility and you have to write code for any extension and *you* will have to maintain them. By using world standards you get the huge benefit of other people and companies endeavours.

…

On Mon, Jan 31, 2022 at 11:18 AM Kevin Jablonka ***@***.***> wrote: stats about how JSON took over XML are here https://twobithistory.org/2017/09/21/the-rise-and-rise-of-json.html — Reply to this email directly, view it on GitHub <#28 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAFTCS7MFVO7IFN7HFY36IDUYZVZFANCNFSM5MVIQH7A> . Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>. You are receiving this because you commented.Message ID: ***@***.***>

-- Peter Murray-Rust Founder ContentMine.org and Reader Emeritus in Molecular Informatics Dept. Of Chemistry, University of Cambridge, CB2 1EW, UK

[kjappelbaum]

The danger in rejecting these is that you end up with a limited, non-extensible domain-specific language

I wonder if JCAMP is also one of those? I think JCAMP is a wonderful idea and it has done a great job in coming up with at least some vocabularies. However, no language brings native support for parsing this (and it can get complicated quickly if you start adding the compression, and some data cannot be represented in JCAMP).

We once, internally, had a discussion about "reviving" JCAMP and the best we could up with is to have a JSON in a comment field in the JCAMP ...

[ml-evs]

Not sure where the best place to post this is, but this is the most active technical discussion and it may be useful feedstock for the panel. Here is a draft of one of the slides from the organizer talk that situates some of the technologies/formats/standards that are being discussing here and where they fall on the file format -> data model -> resource layout -> resource description scale. Of course this is not exhaustive, but if anything extremely relevant (e.g. InChI) is missing then I can add it to the slide:

Aim for me now is to somehow weave in the ecosystem of archives (Zenodo, institutional, figshare etc), domain repositories (MaterialsCloud, NOMAD), databases (OPTIMADE, Chemspider, COD, Materials Project, etc.) and specific research project databases (dynamic) and datasets (static).

[kjappelbaum]

Rehashed version, will keep editing.

Feasibility of semantic techniques

In the talks so far, we have seen already that many propose the use of semantic techniques. However, there is a large opportunity cost with going semantic. You have to learn a completely new ecosystem, it feels. “The reasons are complex but it basically boils down to: going through all the effort of putting semantic markup with no guarantee of a payoff for yourself was a stupid idea.”

1. Is it worth the effort? Do we actually have use cases for all of this in mind? Or success stories we could share?
   What would be a simple demonstrator (e.g., data explorer tools) that one could build to show the use of these tools?

2. A lot of this works really well if you have a finite number stable, well-defined concepts. However, in some parts of chemistry - I think of inorganic chemistry - the focus of the research is to break the rules and to get new insights into basic concepts. For instance, a chemical bond is nothing else than a convenient fiction that might work well for many parts of “standard” organic chemistry but is relatively useless in inorganic chemistry. (see also Shirky: Ontology is Overrated -- Categories, Links, and Tags)

• Also in biology it seems that it does not work across all fields. For instance, ecology seems way more fuzzy than the typical gene -> mRNA -> protein dogma. Is chemistry simply like ecology across the board, or what are the parts you think are easy to codify and one should start focussing on.
• Is it actually feasible in such a case to come up with a workable representation?
• To what extent does the structure of the knowledge graph impact the questions we can ask/answer? - Links to Cory Doctorow “schemas aren’t neural” in metacrap

3. Semantic technologies depend on URIs/IRIs. However, can we mint an identifier for every compound or instrument?

• What do we do when the substance is ill defined (polymers, alloys, …) and how do we decide what is ill-defined? There will always be impurities in experiment, so how can we make sure we talk about the same thing?
• This shows the huge importance of provenance / tracking the history of a sample. Not only might this give you a way to better understand why the sample is as it is, but also you capture that some processes might be destructive to samples (which is quite different from simulations).
  • What are the technologies we have available to capture this provenance of samples? How could we make it accessible to the users and how would we query it?
• Not only samples change, but also schemas do. What happens when the schema changes during an experiment? (Thinking of something like cambria or a ledger of graph operations) What are the technologies we can use for that?

4. What is the minimal effort solution everyone should already use right now? Just a full dump of the database (because we can anyhow not envision every possible use case for an API)?

How do we actually capture the data?

1. It is relatively clear that if we speak about experimental data, chemists will not manually use RDF or something like that. The data they have is maybe digital, but then often in some kind of supplier-specific format or in their minds, or paper-written lab notebooks.

   If we would just provide them with a huge form that captures every eventuality, no one will use this. How do we deal with that? How do we ensure that chemists are not slowed down but we still have their data in structured form? Do we have to resort to NLP in the end? Or if we think about ELN, do we need to provide some kind of tooling to create and disseminate custom schemas?

2. A huge part of making this work seems to be tooling. If you look at the landscapes for tooling it seems pretty scattered. People develop their own ELNs, their own parsers. Their own structure editors and it is often pretty hard to reuse things - it might be easier to write this from scratch. How can we ensure that we avoid replication of work, make tools interoperable and maintainable?

   For instance, is there a way in which we could envision a module system (drag and drop visualizers/editors from an app store together to build your own ELN) for ELNs? What would be needed to make this possible?

3. What tool do you think is missing at the moment? Or what technology do we have that is really underused in the chemistry domain?

4. A lot of work in chemistry still happens using old legacy software/tools/instruments. It won’t be feasible to directly move all into a new technology stack. What can we do to still not lose these parts?

   1. Perhaps more concretely, there are some tools that are used by all (DMFit, Brukers NMR software, what not) and it is really hard (and perhaps a waste of time to re-develop). How do we bring this software into the picture?
      You might envision this provenance graph where you have, so far, performed all operations using open tools, perhaps even integrated in some kind of ELN, but now you perform something in some kind of proprietary software. What is the best way to capture this operation without breaking the provenance graph?

Quality (control)

Following Fletcher et al reliable data is (see also Donny's post)

• “clean” – formatted uniformly, conforming to certain rules/schema, etc.
• grounded in shared meaning spaces – names are unambiguous
• supplied with context – where it comes from, how it was sourced
• accessible in a standardized format – easily imported
• maintained – kept up-to-date

If we want to use the data for ML purposes, we do want to have high-quality, high-fidelity data. However, quoting metacrap, people make typos all the time, people are stupid, people lie.

How do we handle quality control in this setting? What do you think would be a good mechanism?

Should there be a review process upon publication (as in the chemotion repository). Should there be a system of votes, comments, pull reviews (similar to open source software)?

Linked to that:

• Do we envision a future in which we have subject specific repositories, institutional repositories, or everyone just hosts their own data? Or do we split data across different repositories?
  • For instance, if I have a joint experimental-computational study, do i provide my experimental data on the chemotion repository and the computational data on the materials cloud (and then have a harder time reconstructing the link) or do we just dump it all somewhere?
• What is the way to go?

Will someone maintain this?

• In the bio community the pioneers seem to have gotten faculty positions and then the development slowed down.

  • How can we keep the development going? How can we keep the project alive and maintained — also in the face of funding that might be gone 5 or 10 years from now.

• What registries do we need?

• How do we produce useful results?

  “There are many reasons that a working group filled with experts don’t consistently produce great results. For example, many of the participants can be humble about their knowledge so they tend to think that a good chunk of the people that will be using their technology will be just as enlightened. Bad feature ideas can be argued for months and rationalized because smart people, lacking any sort of compelling real world data, are great at debating and rationalizing bad decisions.”

  In some sense, we might also be in some kind of ivory tower. How do we ensure that the stuff we make is still grounded in reality? How do we enable “bench chemists” to be part of the journey?

[kjappelbaum]

Still want to bring up open-world hypothesis and data documentation in band

[kjappelbaum]

shared 20220203_madices_panel_themes.pdf
with the panelists

[petermr]

Thank you, this is a very useful list. Some of the "we hate the SWeb/XML/Schemas" etc probably relate to trying to solve everything, the limited toolset and the novelty. We've come a long way in the last few years and I'm generally optimistic that there are limited valuable solutions *in materials science". My recommendation is that we find subsets of materials science that: * are of interest to a critical mass of people * includes people prepared to experiment with code and data structures * show rapid benefit We explored most of these areas in CML (polymers, mixtures, non-stoichimetry, non-bonds, reactions, spectra, declarative computing *and created running code*. So I am strongly asserting that in materials science it is possible to create semantic tools covering useful subsections of the discipline. The SW naysayers are generally talking about much broader problems than a single scientific discipline, often several years ago, without modern tolols and Wikidata. As inspiration: * reductionist bioscience (genes -> proteins - > enzymes -> metabolism) is already highly semantic. (We are abstracting metabolic pathways from the literature in semantic form). * crystallography - the whole experiment is captured as much as we actually understand the science. If we think it's valuable we have a new CIF dictionary. The easiest of all sciences to semanticise is computation, especially compchem. The only reason it isn't already fully semantic is restrictive practices (in companies and some academia) and a fragmented "market". In bioscience it would have been done by now and be part of the infrastructure. It's the easiest technical starting point since all programs basically do the same experiment. "Compute the structures and energies for this substance (molecule or crystal) with this Wikidata ID, using this method (ID) with basis set (ID) functionals (ID) and calculate properties P1(ID), P2 (ID) under these constraints (Param (ID))" . The next easiest is physical properties. These have a defined data type (scalar, matrix, tensor, etc). That extends to bundles such as spectra or electrochemical measurements. A lot of recipes are tractable, We took X , mixed with Y, in solvent Z , filtered A, purified with P to give A1 ... This is a narrative with defined objects. Most of the objects are already well definable. We need a narrative structure to tie the events together - I'd start with HTML, including defined objects, and free text for the narrative and gradually semanticize some of the verbs. There are enough success stories of determined, people / small_grouos that I think this can work. JMol, Figshare are examples which have captured the world. Comments on Kevin's list below...

On Tue, Feb 1, 2022 at 8:22 AM Kevin Jablonka ***@***.***> wrote: Rehashed version, will keep editing. *Feasibility of semantic techniques* 1. Is it worth the effort? Yes, absolutely. There is no alternative - we cannot survive by sighted

humans reading PDFs and retyping.

1. Do we actually have use cases for all of this in mind? Or success stories we could share? This is critical. Pick one that can work and be useful. Don't try to do

all of materials science.

- What would be a simple demonstrator (e.g., data explorer tools) that one could build to show the use of these tools? The opportunities include:

* discovery (all papers about X, Y ...) This can be rapid - all preprints this week with X, Y... * automation - making repeated jobs automatic. Universities don't cost grad student labour but the time wasted is huge * quality - automation avoids human mistakes * aggregation - collecting "all" the data on a subsystem * workflow - chaining together different operations

- 1. A lot of this works really well if you have a finite number stable, well-defined concepts. Yes - and we should identify these. CML has reaction, spectrum, property,

fragment, etc.

1. However, in some parts of chemistry - I think of inorganic chemistry - the focus of the research is to break the rules and to get new insights into basic concepts. For instance, a chemical bond is nothing else than a convenient fiction that might work well for many parts of “standard” organic chemistry but is relatively useless in inorganic chemistry. (see also Shirky: Ontology is Overrated -- Categories, Links, and Tags <https://digitalcuration.umaine.edu/resources/shirky_ontology_is_overrated.pdf> ) In CML a bond is a styled, annotated line drawn on paper. In organic

molecules it's generally useful enough to use graph theory for searching and creating subcomponents. In solid state it probably has no use.

- Is it actually feasible in such a case to come up with a workable representation? - To what extent does the structure of the knowledge graph impact the questions we can ask/answer? - Links to Cory Doctorow “schemas aren’t neural” in metacrap <https://chnm.gmu.edu/digitalhistory/links/pdf/preserving/8_17.pdf> I know and respect Cory but this is a 20-yr old, very broad criticism. . 1. Semantic technologies depend on URIs/IRIs. However, can we mint an identifier for every compound or instrument? For purified stoichiometric compounds it's been done for over 50 years by

CAS. The problem is political. Pubchem and Wikidata are rapidly building an acceptable alternative. For non-stoichometry we need free variables (Mg(x), Ca(1-x), ) etc. CML did this. Marketed instruments should be straightforward and can be scraped from the literature and added to Wikidata.

- What do we do when the substance is ill defined (polymers, alloys, …) and how do we decide what is ill-defined? There will always be impurities in experiment, so how can we make sure we talk about the same thing? That's hard. We spent years on polymers (and created

PolymerMarkupLanguage). But the conclusion was that the processing was often more important than the simple composition. If you don't understand the science completely, you can't easily make it semantic.

- This shows the huge importance of provenance / tracking the history of a sample. Not only might this give you a way to better understand why the sample is as it is, but also you capture that some processes might be destructive to samples (which is quite different from simulations). - What are the technologies we have available to capture this provenance of samples? How could we make it accessible to the users and how would we query it? I suspect this has to be largely by Natural Language Processing (NLP) . We

have built this for organic syntheses (http://chemicaltagger.ch.cam.ac.uk/). The architecture allows it to be extended for other domains (we did atmospheric chemistry). ... This is in danger of turning into a huge interleaved document, so I'll stop for breath. The analysis, and preparation for this meeting is impressive . The most important thing is that this is seen as a long-term process. It can't be solved in 2 years. We set up the Blue Obelisk ( https://en.wikipedia.org/wiki/Blue_Obelisk) 17 years ago and it's brought a lot of people and software into better synchronisation than without it. It's one of many social models that has had some success. TL;DR - it's hard, committed work but it's possible to make enough useful progress in a few subdomains to show the world a new future. P.

…

-- Peter Murray-Rust Founder ContentMine.org and Reader Emeritus in Molecular Informatics Dept. Of Chemistry, University of Cambridge, CB2 1EW, UK

[petermr]

You asked two questions:

• Is it worth it?
  Yes.
  The human genome is worth it. It's built on PERL.
  They didn't know they could do it when they started but they had faith.
  • is it feasible?
    Yes.
    My optimism comes from the vastly improved infrastructure and tooling.

I think our systems will be massively hybrid. The current generation of software allows different technologies to be mixed. The (apparent) limitations of RDF. XML etc. were frequently about needing to do everything in a single language. (Tim BL tried to convince me to implement chemistry in triples - it doesn't work - you need containers.|

We need chunking/containment and we need links/relations and they need different technologies. We can identify the current technologies that work for particular problems and use them to "chunk" the system. a "spectrum" is a chunk. We often don't need to look inside the details. Biblography is a chunk. It's a solved problem. So are crystal structures. So are covalent molecules, etc.
RDF is terrible for describing the details but good for typing them together.
Yes it will be clunky but so was PERL
This prototype will work well enough to be useful for many and inform the next generation of design.

[kjappelbaum]

Tim BL tried to convince me to implement chemistry in triples - it doesn't work - you need containers.|

I would love to hear more about this. It is not so clear what breakout room would fit best - maybe #5 or we could bring this up in panel discussion 2.

Yes it will be clunky but so was PERL

Python/PERL might be a nice comparison. I guess the Python case study shows that a good ecosystem of libraries helps.

[kjappelbaum]

perhaps something valueable to do is to look for libraries such as https://github.com/cadmiumkitty/rdfpandas that provide a starting point to use existing technologies that everyone uses (pandas) to make them with minimal effort more reusable/interoperable

one nice takeaway for me would be to discover some new packages that I could contribute to or that I could easily integrate into the technology stack that I'm already using (and ideally, also convert into valuable output i can show to my boss ;) )

[petermr]

>PMR: Tim BL tried to convince me to implement chemistry in triples - it

doesn't work - you need containers.KJ: I would love to hear more about this. 1997-ish Tim had a view that the whole world can be represented in RDF. But it doesn't fit into most people's brains (and it also only worked then with toy examples). In the early years of the web there was very little client-side code - I had to write my own menu system in Java. Computer scientists had been building theoretical views of the world, so many thought this was the chance to put them into practice. By building in OWL we could validate and compute reality. Triple stores were the magic solution It didn't work - there wasn't enough data and there wasn't enough code and it didn't interoperate. So the Web forged ahead with whatever people liked working with. Some of the early web was based on pragmatics - others on theory. XML, XPath were pragmatic. They worked, XSLT and XSD were driven by theoretical designs, inspired by LISP, and left most people behind. They are complex and overengineered. There's a lot of remains of unsuccessful experiments It's important that today's approaches are both machine- *and* people-friendly. If we all agree what something is, it's generally not so difficult to write code, and it also provides "chunking" where our brains don't have to worry about the details. <molecule>...</molecule> is a well defined chunk, whereas doing it in B-nodes is a mess of wiring. The chunks give the same freedom as integrated circuits did - you don't have to worry about what's inside. We need integrated knowledge components for materials - crystals, surfaces, mixtures, measurements, synthesis. Since it's the first time through this exercise not all the bits will work out. But we know a lot about the system to start with. We need chunks and we need links. XML or JSON does well for chunks. Fixed format files (like SDF/MOL cannot provide extensibility and they cannot support links) The chunks need links to the outside world and for that we need well defined connection points (such as "id" attributes) and semantic relations such as what RDF provides. And "running code" P.

--

Peter Murray-Rust Founder ContentMine.org and Reader Emeritus in Molecular Informatics Dept. Of Chemistry, University of Cambridge, CB2 1EW, UK