search

ec-geolink / design

Design information about the EarthCube Geolink project.
8 stars 1 forks source link

Base ontology: Vocabulary for Mineral/Material Types #67

Open krisnadhi opened 9 years ago

krisnadhi commented 9 years ago

@robertarko's question via private email:

We are developing the vocabulary of mineral types (based on SESAR) for schema.geolink.org.

We have a mineral type eg. "Aleksite". We would like to indicate, Aleksite has code "1977-038" in the International Mineral Association (IMA) database. How shall we encode this information in our OWL file ? rdfs:seeAlso ?

I think we cannot use gl:hasIdentifier, because we only use hasIdentifier for Linked Data resources (not OWL classes). Right ?

krisnadhi commented 9 years ago

Hmmm… currently we have the following data properties: hasMaterial (range: xsd:anyURI) and hasMaterialType (range: xsd:anyURI or xsd:string), which I haven’t changed yet to reflect our recent discussion.

I propose the following and if you (@robertarko and @sparkji) agree, I can initiate the OWL file:

  1. create a new OWL file: design/voc/ima/mineraltype.owl
  2. ontology URI of the above file is: http://schema.geolink.org/dev/voc/ima/mineraltype
  3. Since IMA database doesn’t provide URIs for the mineral types, we need to mint our own URIs. For example, for Aeschynite-(Ce), we mint the URI: http://schema.geolink.org/dev/voc/ima/mineraltype#Aeschynite-Ce, or assuming that glvoc_ima is the prefix defined for http://schema.geolink.org/dev/voc/ima/mineraltype#, the URI is glvoc_ima:Aeschynite-Ce. Alternatively,

  4. The minted URI above should be declared as both class and individual, and we also declare that:

    glvoc_ima:Aeschynite-Ce rdf:type gl:MaterialType glvoc_ima:Aeschynite-Ce rdfs:subClassOf gl:Material

  5. We also add label and reference to IMA through rdfs:label and rdfs:seeAlso, so we could have something like:

    glvoc_ima:Aeschynite-Ce rdfs:label "Aeschynite-(Ce)" glvoc_ima:Aeschnyte-Ce rdfs:seeAlso <http://pubsites.uws.edu.au/ima-cnmnc/imalist.htm>

  6. There will be a simple typecasting axiom added for each minted URI, just like in the OWL files for GEBCO feature types and NERC vocabularies.
  7. Regarding IMA identifier, the properties hasIdentifier, hasIdentifierScheme, and hasIdentifierValue are intended for indentifier of data, not vocabulary terms. We could still use them of course, but within some OWL axiom. I can implement this if you want.

  8. For the data, you can publish physical samples in the form of something like:

    :physicalsample1 rdf:type gl:PhysicalSample ; gl:hasMaterialType glvoc_ima:Aeschynite-Ce .

bob-arko commented 9 years ago

Okay we think we understand. :)

So basically this: glvoc_ima:Aeschynite-Ce rdf:type gl:MaterialType glvoc_ima:Aeschynite-Ce rdfs:subClassOf gl:Material would be the same approach we've used for GEBCO and NVS. Good to be consistent.

So, Adila will create a OWL file for the IMA materialtypes in the schema.geolink.org namespace, as above.

Meanwhile Peng will create a OWL file for SESAR materialtypes in his local (schema.geosamples.org) namespace. And he will map the subset of SESAR materialtypes that match IMA materialtypes. But not using :hasIdentifier. What property should we use ? Do we need a new one?

On Mon, Sep 14, 2015 at 11:23:33AM -0700, krisnadhi wrote:

Hmmm… currently we have the following data properties: hasMaterial (range: xsd:anyURI) and hasMaterialType (range: xsd:anyURI or xsd:string), which I haven’t changed yet to reflect our recent discussion.

I propose the following and if you (@robertarko and @sparkji) agree, I can initiate the OWL file:

  1. create a new OWL file: design/voc/ima/mineraltype.owl
  2. ontology URI of the above file is: http://schema.geolink.org/dev/voc/ima/mineraltype
  3. Since IMA database doesn’t provide URIs for the mineral types, we need to mint our own URIs. For example, for Aeschynite-(Ce), we mint the URI: http://schema.geolink.org/dev/voc/ima/mineraltype#Aeschynite-Ce, or assuming that glvoc_ima is the prefix defined for http://schema.geolink.org/dev/voc/ima/mineraltype#, the URI is glvoc_ima:Aeschynite-Ce. Alternatively,

  4. The minted URI above should be declared as both class and individual, and we also declare that:

    glvoc_ima:Aeschynite-Ce rdf:type gl:MaterialType glvoc_ima:Aeschynite-Ce rdfs:subClassOf gl:Material

  5. We also add label and reference to IMA through rdfs:label and rdfs:seeAlso, so we could have something like:

    glvoc_ima:Aeschynite-Ce rdfs:label "Aeschynite-(Ce)" glvoc_ima:Aeschnyte-Ce rdfs:seeAlso <http://pubsites.uws.edu.au/ima-cnmnc/imalist.htm>

  6. There will be a simple typecasting axiom added for each minted URI, just like in the OWL files for GEBCO feature types and NERC vocabularies.
  7. Regarding IMA identifier, the properties hasIdentifier, hasIdentifierScheme, and hasIdentifierValue are intended for indentifier of data, not vocabulary terms. We could still use them of course, but within some OWL axiom. I can implement this if you want.

  8. For the data, you can publish physical samples in the form of something like:

    :physicalsample1 rdf:type gl:PhysicalSample ; gl:hasMaterialType glvoc_ima:Aeschynite-Ce .

Reply to this email directly or view it on GitHub: https://github.com/ec-geolink/design/issues/67#issuecomment-140166146

krisnadhi commented 9 years ago

Oh I didn't know that you plan to create your own OWL file in your local namespace. What's the purpose of SESAR's OWL file?

bob-arko commented 9 years ago
  1. SESAR has a wide variety of material types (rocks, minerals, fluids, soils, etc). This is a SESAR home-grown vocabulary . So it should be in the SESAR namespace.
  2. IMA has an authoritative list of one specific material type (minerals). But their vocabulary is not published online as OWL classes. So we will publish it at schema.geolink.org as an interim solution.
  3. We want to map SESAR's minerals to IMA's minerals wherever possible. This shows the geologists that we respect int'l standards where possible.

On Mon, Sep 14, 2015 at 02:02:16PM -0700, krisnadhi wrote:

Oh I didn't know that you plan to create your own OWL file in your local namespace. What's the purpose of SESAR's OWL file?

krisnadhi commented 9 years ago

Okay. I have no problem creating IMA-specific OWL file. What I wondered about was whether there is some SESAR vocabulary terms for which GeoLink should not have a corresponding term. From your explanation, the SESAR vocabulary term is not intended to be used by other parties outside SESAR?

In any case, regarding identifiers, gl:hasIdentifier property was intended to be used for data, but not for vocabulary terms. Let me try solving this first, and see what I get.

sparkji commented 9 years ago

We has same issue for GVP and SCAR gazetteer. They are used like GEBOCO features, both of them do not publish URIs that speak RDF. But GVP provides unique URL for each volcano like http://volcano.si.edu/volcano.cfm?vn=210010 http://volcano.si.edu/volcano.cfm?vn=210010, so could we just directly use this URL as the identifier of volcano 'West Eifel Volcanic Field'?

It's kind of complicated for SCAR. SCAR has two identifiers, one is Place ID, another is Name ID. For Example, the feature 'Barden Mount' listed below:

Barden, Mount (RUS) Name ID:116960 Place ID:883 link: https://www1.data.antarctica.gov.au/aadc/gaz/scar/display_name.cfm?gaz_id=116960 Barden, Mount (USA) Name ID:122185 Place ID:883 link: https://www1.data.antarctica.gov.au/aadc/gaz/scar/display_name.cfm?gaz_id=122185

They are the same place, but Authorized by different counties. For my view, I'd like to use place ID 883 as the identifier for feature 'Barden Mount', but there is no URL for Place ID 883 in SCAR. So, do we need create SCAR-specific owl file under geolink domain?

On Mon, Sep 14, 2015 at 5:53 PM, krisnadhi notifications@github.com wrote:

Okay. I have no problem creating IMA-specific OWL file. What I wondered about was whether there is some SESAR vocabulary terms for which GeoLink should not have a corresponding term. From your explanation, the SESAR vocabulary term is not intended to be used by other parties outside SESAR?

In any case, regarding identifiers, gl:hasIdentifier property was intended to be used for data, but not for vocabulary terms. Let me try solving this first, and see what I got.

— Reply to this email directly or view it on GitHub https://github.com/ec-geolink/design/issues/67#issuecomment-140215819.

krisnadhi commented 9 years ago

On Sep 15, 2015, at 12:46 PM, Peng notifications@github.com wrote:

We has same issue for GVP and SCAR gazetteer. They are used like GEBOCO features, both of them do not publish URIs that speak RDF. But GVP provides unique URL for each volcano like http://volcano.si.edu/volcano.cfm?vn=210010 http://volcano.si.edu/volcano.cfm?vn=210010, so could we just directly use this URL as the identifier of volcano 'West Eifel Volcanic Field’?

If possible, I would rather not use this URL as the identifier since it is not a cool URI (Stability aspect according to http://www.w3.org/TR/cooluris/#cooluris http://www.w3.org/TR/cooluris/#cooluris).

It's kind of complicated for SCAR. SCAR has two identifiers, one is Place ID, another is Name ID. For Example, the feature 'Barden Mount' listed below:

Barden, Mount (RUS) Name ID:116960 Place ID:883 link: https://www1.data.antarctica.gov.au/aadc/gaz/scar/display_name.cfm?gaz_id=116960 Barden, Mount (USA) Name ID:122185 Place ID:883 link: https://www1.data.antarctica.gov.au/aadc/gaz/scar/display_name.cfm?gaz_id=122185

They are the same place, but Authorized by different counties. For my view, I'd like to use place ID 883 as the identifier for feature 'Barden Mount', but there is no URL for Place ID 883 in SCAR. So, do we need create SCAR-specific owl file under geolink domain?

Isn’t this similar to GEBCO features? We could create a SCAR-specific OWL file to list all the features like in the GEBCO OWL file. The features will be instances of FeatureType class. Regarding the Name ID, is there a case where the same feature has two different names which are displayed completely differently? (At least, to me, Barden Mount seems to appear the same way both from the US and Russia’s perspectives).