Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

How to link datasets to physical samples #16

Open
ashepherd opened this issue Mar 19, 2018 · 2 comments
Open

How to link datasets to physical samples #16

ashepherd opened this issue Mar 19, 2018 · 2 comments

Comments

@ashepherd
Copy link
Contributor

@fils, @smrgeoinfo

{
  "@type": "Dataset",
  ...
  "hasPart": [
    {
      "@type": "CreativeWork",
      "additionalType": "http://schema.geolink.org/1.0/base/main#PhysicalSample",
      ... first sample...
    },
    {
      "@type": "CreativeWork",
      "additionalType": "http://schema.geolink.org/1.0/base/main#PhysicalSample",
      ... second sample ...
    },
  ]
}
@smrgeoinfo
Copy link

Given the limited scope of schema.org, using 'hasPart' seems like the least unlikely relation to use for now as a proof of concept.

In the long run, we really need to think about the purpose of this schema.org markup. There are already lots of better defined metadata vocabularies and standards out there that are in wide use for scientific data. What are we gaining by ad hoc use of relationships like this to get information we're interested in into the SDO markup, when there are already mechanisms to publish the metadata in xml or using other rdf vocabularies (Prov, geoDCAT-AP) that are designed for the information we're interested in. If the commercial search engines are interested in data, wouldn't in make more sense for them to figure out how to index existing metadata?

In the meantime, I'll go ahead and implement 'hasPart' for linking the Earthchem Library datasets to IGSNs where the information exists.

extended example with IGSN:

"hasPart": [
    {
      "@type": "CreativeWork",
      "additionalType": "http://schema.geolink.org/1.0/base/main#PhysicalSample",
      ... first sample...
      "identifier": {
        "@type": "PropertyValue",
        "additionalType": ["http://schema.geolink.org/1.0/base/main#Identifier", "http://purl.org/spar/datacite/Identifier"],
        "name": "IGSN goes here",
        "propertyID": "IGSN",
        "url": "https://app.geosamples.org/sample/igsn/WHO000A52",
        "value": "WHO000A52"
      },
      ...
    },
    {
      "@type": "CreativeWork",
      "additionalType": "http://schema.geolink.org/1.0/base/main#PhysicalSample",
      ... second sample ...
      "identifier": {
        "@type": "PropertyValue",
        "additionalType": ["http://schema.geolink.org/1.0/base/main#Identifier", "http://purl.org/spar/datacite/Identifier"],
        "name": "IGSN goes here",
        "propertyID": "IGSN",
        "url": "https://app.geosamples.org/sample/igsn/WHO000A53",
        "value": "WHO000A53"
      }
      ...
    }
  ]

@mbjones
Copy link

mbjones commented Mar 22, 2018

@smrgeoinfo totally agree on needing to decide what SDO is "for". I think domain metadata standards are too niche for the big search engines to grapple with. But their happy to deal with something the size of Wikipedia, and I think more happy if we spend the time mapping domain info onto their chosen model. That it isn't as precise as the domain metadata isn't probably their biggest concern. The one nice thing about everyone mapping to SDO is we seem to be achieving pretty broad consensus on vocabularies, just because everyone wants to be compatible with the search engines, although we are losing precision along the way.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants