Guidance on how to use sameAs

[goeffthomas]

Our own docs specify to use the sameAs property to flag "The URL of another Web resource that represents the same dataset as this one.". What level of "sameness" are we okay with here? For example, Kaggle is working together with OpenML to identify datasets across the two platforms that are the same in order to link them in the UI (and in Croissant). In some cases, column names and ordering make up the only difference between some valid matches. Is this still satisfactory for flagging with sameAs? The hashes for the files wouldn't match, so I'm wondering what kind of expectation we may hope to communicate with sameAs.

Let's take it one step further. Let's say we're okay with this situation where column naming and ordering is different but some column has been converted from a string-based "T"/"F" to a bool-oriented 1/0? Is that also good enough?

Or is all of this up for interpretation on a per-user/repo basis?

[benjelloun]

Great question! My take on it is that sameAs is talking about the object being described, so the question is: Is it the same dataset? I would tend to say that if column order was changed or the representation of some field was modified, then it's still the same dataset, so using sameAs is okay.

That said... the definition of sameAs in schema.org is a bit more stringent: URL of a reference Web page that unambiguously indicates the item's identity. E.g. the URL of the item's Wikipedia page, Wikidata entry, or official website.

So in theory, sameAs should be used to point to a "canonical" url for the dataset (such as a DOI, or a reference page for the dataset, e.g., from its original provider), and not as a way to map between two non-canonical versions of the dataset. But, there is no simple property we can use instead that is readily available in schema.org

The solutions I see are:

1. continue to use sameAs to denote that two datasets ini different repositories are the same dataset, modulo isomorphic changes in representation

2. Introduce another property in croissant, e.g., cr:equivalentDataset, and clarify restrictions on using sameAs

3. Treat this as a special case of modeling lineage / relationships between datasets, e.g., along the lines of https://www.w3.org/TR/vocab-dcat-3/#qualified-forms

I'm leaning towards 1, as it's the simplest approach, and it may be difficult for users to know which URL is a canonical one for a given dataset. WDYT?

[goeffthomas]

I tend to prefer an iterative approach when possible, so starting with the simplest version and then modifying later fits with that. Luckily, we have versioning in Croissant, so if we decide to make this change later, we can capture it effectively.

One thought I had that might throw a wrench in this is understanding how/where Croissant is expected to be used. Granted, it's still early days so some of this is yet to be fleshed out, but if the assumption is that code is to be written against the consumption of these tables, I wonder if column name differences or field representation changes might "break" a users code. They might assume that sameAs means they're interoperable but would get NREs when referencing the differently named columns, or perhaps some runtime issue when consuming strings that were expected to be numerical (or vice versa).

That said, maybe that's not something we expect to be responsible for managing on behalf of users. Maybe we just load the data for them and they massage where needed to fit their purpose. Does any of this affect your opinion? I'm still okay going with option 1 so long as we're aware that a pivot like number 2 or 3 may be needed at a certain point.