Feedback for base ontology.

[krisnadhi]

Any feedback to the base ontology can be collected here.

File is here: https://github.com/ec-geolink/design/blob/master/patterns/producer-centric-views/main.owl

cc: @robertarko @ashepherd @fils @mbjones @amoeba @narock @mcheatham @Nazifa115 @YingjieHu @atmickle @sparkji

[bob-arko]

Suggest changing "SubmersibleDive" to simply "Dive".

(analogous to Vessel -> Cruise)

[bob-arko]

Suggest adding class Measurement (in addition to MeasurementType).

[bob-arko]

Suggest changing hasGeologicUnit to hasStratigraphicUnit.

Values could eventually draw from a small controlled vocabulary eg. lithostratigraphic (Formation, Group, Member, Bed, Flow) or biostratigraphic (Assemblage, Range, Abundance, Interval, Lineage).

[atmickle]

Suggest changing the definition of Document from "A citable, creative work" to something a little closer to what we talked about at the meeting, like "A textual, word-based, non-structured expression of information, such as a report, presentation, published article, or lecture." Or something less pedantic...

[bob-arko]

Suggest the range of PhysicalSample.hasStratigraphicUnit is a gazetteer of named instances (eg. from the USGS National Geologic Map Database):

Bonneville Formation Portland Formation Gray Gulch Formation etc.

Doug - comments ?

[sparkji]

Suggest changing "hasOriginFeature" to "hasFeatureOfInterest"

On Wed, Sep 2, 2015 at 6:52 PM, krisnadhi notifications@github.com wrote:

Any feedback to the base ontology can be collected here.

File is here: https://github.com/ec-geolink/design/blob/master/patterns/producer-centric-views/main.owl

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

[mbjones]

@robertarko Can you explain your request to add 'Measurement' as a class in addition to 'MeasurementType'? Are you proposing 'glbase:Measurement' as an equivalentClass to oml:Observation and oboe:Measurement?

Also, I'd like to clarify the definition of glbase:MeasurementType, which is currently ambiguous. We need to be clearer with respect to the detailed work on measurements that has come before.

[mbjones]

Suggest changing range of hasByteLength from xsd:int to xsd:positiveInteger or owl:real to accommodate larger sized objects.

[mbjones]

Question: why is the range of hasElevation set to xsd:string? Shouldn't that be a numeric quantity, and are units implied?

[sparkji]

Comments: In SESAR, elevation is a range, we use elevation, elevation_end and elevation unit to indicate it, so, xsd:string is good for our case, we could use the format like ' 10 to 100 m' to fill 'hasElevation' property.

On Thu, Sep 3, 2015 at 2:39 PM, Matt Jones notifications@github.com wrote:

Question: why is the range of hasElevation set to xsd:string? Shouldn't that be a numeric quantity, and are units implied?

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

[mbjones]

@sparkji thanks for the explanation. Maybe the property should be renamed hasElevationDescription, to differentiate it from a future property that might be more quantitative and constrained.

[mbjones]

Suggest changing hasIdentifierScheme to an ObjectProperty. I'm not sure why its a DatatypeProperty now. Thoughts?

[mbjones]

Suggest changing range of hasPublicationDate to allow for dates that are just years. xsd:dateTime requires a full date value, whereas many publication dates are just represented by the year (e.g., 2015, not 2015-02-09). We usually accomplish this via a union of xsd:dateTime and xsd:gYear.

[sparkji]

Suggest adding union range 'Organization' and 'Repository' for property 'hasPhysicalReopsitory'. In SESAR case, users maybe use both, like LDEO, or LDEO core repository, the former is organization, the latter is repository.

On Wed, Sep 2, 2015 at 6:52 PM, krisnadhi notifications@github.com wrote:

Any feedback to the base ontology can be collected here.

File is here: https://github.com/ec-geolink/design/blob/master/patterns/producer-centric-views/main.owl

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

[sparkji]

Suggest adding new class 'Material' , 'MaterialType' and 'SamplingType'.

On Wed, Sep 2, 2015 at 6:52 PM, krisnadhi notifications@github.com wrote:

Any feedback to the base ontology can be collected here.

File is here: https://github.com/ec-geolink/design/blob/master/patterns/producer-centric-views/main.owl

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

[sparkji]

Makes sense to me. So a MaterialType would be eg. "Mineral".. and instances of Material would be Acanthite, Almandine, Anhydrite, ..

On Fri, Sep 04, 2015 at 01:20:37PM -0400, Peng Ji wrote:

Suggest adding new class 'Material' , 'MaterialType' and 'SamplingType'.

On Wed, Sep 2, 2015 at 6:52 PM, krisnadhi notifications@github.com wrote:

Any feedback to the base ontology can be collected here.

File is here: https://github.com/ec-geolink/design/blob/master/patterns/producer-centric-views/main.owl

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

[amoeba]

@mbjones Strongly agree with changing hasByteLength from xsd:int to something else. I prefer xsd:positiveInteger for its level of specificity but I see that it doesn't allow taking on the value of zero. If there is any chance we'd need to handle hasByteLength of zero, I'd go in for something like owl:real instead.

Also agree with changing hasIdentifierScheme to be an ObjectProperty. Our current use wouldn't be valid unless this is changed. Do we have any identifiers not in the datacite list that are also not datacite:localresourceidentifier? If that's the case, we might also need a glbase:IdentifierScheme or something else to capture those other schemes.

[amoeba]

Suggest moving some DataOne concepts into the GLBase ontology. Current definitions are in https://github.com/ec-geolink/design/blob/master/patterns/producer-centric-views/dataone.owl

• Add hasChecksumAlgorithm: Allows DigitalObjects to have their checksum's algorithm specified. This is a requirement of interpreting glbase:hasChceksum
• Add hasLandingPage: For DataOne resolving the HTTP URIs for Datasets and Digital Objects may result in a response that is just the bytes for that Dataset (e.g. EML XML) or DigitalObject (bytes of a CSV). DataOne maintains a view service at http://search.dataone.org/ that provides a human-readable landing page for DataOneDatasets and DigitalObjects. Could other groups use this or should this just stay in dataone.owl?
• Add dateUploaded: Allows Datasets and DigitalObjects to reference a datetime of when they were uploaded.
• Expand range of hasStartDate and hasEndDate to include Dataset.

[bob-arko]

• Add hasChecksumAlgorithm:
• Add hasLandingPage:
• Add dateUploaded:
• Expand range of hasStartDate and hasEndDate to include Dataset.

Those all make sense to me, except I think dateUploaded might be ambiguous for some folks. What does that mean ?

[amoeba]

Inside DataOne, we use it as such (emphasis mine):

"Date and time (UTC) that the object was uploaded into the DataONE system, which is typically the time that the object is first created on a Member Node using the MNStorage.create() operation. Note this is independent of the publication or release date of the object. The Member Node must set this optional field when it receives the system metadata document from a client."

Do other GeoLink members need something like that?

[bob-arko]

Right. Makes sense.

As long as every class and property in the owl file has an inline definition (rdfs:comment), should be fine.

On Fri, Sep 04, 2015 at 12:14:47PM -0700, Bryce Mecum wrote:

Inside DataOne, we use it as such (emphasis mine):

"Date and time (UTC) that the object was uploaded into the DataONE system, which is typically the time that the object is first created on a Member Node using the MNStorage.create() operation. Note this is independent of the publication or release date of the object. The Member Node must set this optional field when it receives the system metadata document from a client."

Do other GeoLink members need something like that?

---

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

[bob-arko]

I was thinking a Measurement is an instance having a MeasurementType, Unit, and Value.

MeasurementType, in turn, would typically draw from a controlled vocabulary of commonly measured parameters, such as NVS P02. http://schema.geolink.org/dev/voc/nvs/P02

On Thu, Sep 03, 2015 at 11:19:41AM -0700, Matt Jones wrote:

@robertarko Can you explain your request to add 'Measurement' as a class in addition to 'MeasurementType'? Are you proposing 'glbase:Measurement' as an equivalentClass to oml:Observation and oboe:Measurement?

Also, I'd like to clarify the definition of glbase:MeasurementType, which is currently ambiguous. We need to be clearer with respect to the detailed work on measurements that has come before.

[amoeba]

@robertarko Good point! I've added a comment to it. I tried to match the style of other comments in glbase. See 84fc3b16f850622496acabbec0c7aebabab284ba

@mbjones Does that look good?

[bob-arko]

Agreed, should be ObjectProperty.

On Thu, Sep 03, 2015 at 11:53:33AM -0700, Matt Jones wrote:

Suggest changing hasIdentifierScheme to an ObjectProperty. I'm not sure why its a DatatypeProperty now. Thoughts?

[krisnadhi]

On Sep 3, 2015, at 9:40 AM, robertarko notifications@github.com wrote:

Suggest changing "SubmersibleDive" to simply "Dive”.

Done.

(analogous to Vessel -> Cruise) — Reply to this email directly or view it on GitHub https://github.com/ec-geolink/design/issues/52#issuecomment-137449258.

[krisnadhi]

On Sep 3, 2015, at 9:41 AM, robertarko notifications@github.com wrote:

Suggest changing hasGeologicUnit to hasStratigraphicUnit.

Done.

Values could eventually draw from a small controlled vocabulary eg. lithostratigraphic (Formation, Group, Member, Bed, Flow) or biostratigraphic (Assemblage, Range, Abundance, Interval, Lineage). — Reply to this email directly or view it on GitHub https://github.com/ec-geolink/design/issues/52#issuecomment-137449570.

[krisnadhi]

On Sep 3, 2015, at 12:41 PM, robertarko notifications@github.com wrote:

Suggest the range of PhysicalSample.hasStratigraphicUnit is a gazetteer of named instances (eg. from the USGS National Geologic Map Database):

Bonneville Formation Portland Formation Gray Gulch Formation etc.

Doug - comments ?

Do we want to collect this gazetteer instance into a class in the ontology? If yes, we change the property into ObjectProperty. Otherwise, we simply keep the property as a DataProperty with xsd:anyURI as range.

—adila

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

[krisnadhi]

On Sep 3, 2015, at 10:46 AM, Audrey Mickle notifications@github.com wrote:

Suggest changing the definition of Document from "A citable, creative work" to something a little closer to what we talked about at the meeting, like "A textual, word-based, non-structured expression of information, such as a report, presentation, published article, or lecture." Or something less pedantic...

Done. I don’t think the suggested definition is too pedantic.

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

[krisnadhi]

Okay. I’m not adding this class yet. Waiting for others to comment …

On Sep 4, 2015, at 3:26 PM, robertarko notifications@github.com wrote:

I was thinking a Measurement is an instance having a MeasurementType, Unit, and Value.

MeasurementType, in turn, would typically draw from a controlled vocabulary of commonly measured parameters, such as NVS P02. http://schema.geolink.org/dev/voc/nvs/P02

On Thu, Sep 03, 2015 at 11:19:41AM -0700, Matt Jones wrote:

@robertarko Can you explain your request to add 'Measurement' as a class in addition to 'MeasurementType'? Are you proposing 'glbase:Measurement' as an equivalentClass to oml:Observation and oboe:Measurement?

Also, I'd like to clarify the definition of glbase:MeasurementType, which is currently ambiguous. We need to be clearer with respect to the detailed work on measurements that has come before.

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

[krisnadhi]

On Sep 3, 2015, at 12:52 PM, Peng notifications@github.com wrote:

Suggest changing "hasOriginFeature" to “hasFeatureOfInterest"

Done.

On Wed, Sep 2, 2015 at 6:52 PM, krisnadhi notifications@github.com wrote:

Any feedback to the base ontology can be collected here.

File is here: https://github.com/ec-geolink/design/blob/master/patterns/producer-centric-views/main.owl

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

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

[krisnadhi]

On Sep 3, 2015, at 2:38 PM, Matt Jones notifications@github.com wrote:

Suggest changing range of hasByteLength from xsd:int to xsd:positiveInteger or owl:real to accommodate larger sized objects.

Done: hasByteLength’s range is now owl:real

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

[krisnadhi]

@sparkji any objection in changing hasElevation to hasElevationDescription?

@sparkji thanks for the explanation. Maybe the property should be renamed hasElevationDescription, to differentiate it from a future property that might be more quantitative and constrained.

[krisnadhi]

Also agree with changing hasIdentifierScheme to be an ObjectProperty. Our current use wouldn't be valid unless this is changed. Do we have any identifiers not in the datacite list that are also not datacite:localresourceidentifier? If that's the case, we might also need a glbase:IdentifierScheme or something else to capture those other schemes.

@amoeba @mbjones, If we change hasIdentifierScheme into an ObjectProperty, then we should add IdentifierScheme class to express its range in a simple way. I initially defined this as DataProperty because it wasn't clear if we want to add IdentifierScheme as a new class, and I thought that identifier schemes are any URIs that data providers may provide. But if we all agree on adding IdentifierScheme as a class, then I'll go ahead with the change. Any thoughts, @robertarko @ashepherd ?

[krisnadhi]

Suggest changing range of hasPublicationDate to allow for dates that are just years. xsd:dateTime requires a full date value, whereas many publication dates are just represented by the year (e.g., 2015, not 2015-02-09). We usually accomplish this via a union of xsd:dateTime and xsd:gYear.

hasPublicationDate's range is now xsd:dateTime or xsd:gYearMonth or xsd:gYearMonth

[krisnadhi]

Suggest adding union range 'Organization' and 'Repository' for property 'hasPhysicalReopsitory'. In SESAR case, users maybe use both, like LDEO, or LDEO core repository, the former is organization, the latter is repository.

This would cause inconsistency with hasRepository whose range is only Repository. Any comments @robertarko ?

[krisnadhi]

• Add hasChecksumAlgorithm: Allows DigitalObjects to have their checksum's algorithm specified. This is a requirement of interpreting glbase:hasChceksum

Done.

• Add hasLandingPage: For DataOne resolving the HTTP URIs for Datasets and Digital Objects may result in a response that is just the bytes for that Dataset (e.g. EML XML) or DigitalObject (bytes of a CSV). DataOne maintains a view service at http://search.dataone.org/ that provides a human-readable landing page for DataOneDatasets and DigitalObjects. Could other groups use this or should this just stay in dataone.owl?

Done.

• Add dateUploaded: Allows Datasets and DigitalObjects to reference a datetime of when they were uploaded.

What if we use the term hasUploadDate instead? We already have hasPublicationDate, hasStartDate, and hasEndDate.

• Expand range of hasStartDate and hasEndDate to include Dataset.

You mean the domain? In any case, I added Dataset to the domain of both properties.

[krisnadhi]

Makes sense to me. So a MaterialType would be eg. "Mineral".. and instances of Material would be Acanthite, Almandine, Anhydrite, .

Are they controlled vocabulary terms? Which one uses controlled vocabulary terms: MaterialType or Material or both? If Acanthite, Almandine, etc. are controlled vocabulary terms, aren't they actually material types and not materials?

Any comment @robertarko ?

[sparkji]

MaterialType would be controlled, SESAR uses ODM2 medium vocabulary (http://vocabulary.odm2.org/medium/), like Rock and Mineral. Material would also be controlled, like Acanthite and Almandine are instances of mineral (MaterialType). For mineral type, SESAR would like to use IMA minerals list (http://www.ima-mineralogy.org/Minlist.htm). For rock type, SESAR has its own suggested terms(http://www.geosamples.org/help/vocabularies/rock). Does make sense?

[krisnadhi]

Then, I would model MaterialType and not Material. All those vocabulary terms like Rock, Mineral, Acanthite and Almandine are instances of MaterialTypes. If you insist on adding Material class, I would then add Rock, Mineral, Acanthite and Almandine as subclasses of Material, but not instances.

[amoeba]

What if we use the term hasUploadDate instead? We already have hasPublicationDate, hasStartDate, and hasEndDate.

Agreed. Makes more sense than my suggestion.

You mean the domain? In any case, I added Dataset to the domain of both properties.

Yep, thanks.

[sparkji]

SESAR uses the format list below to store material related information, there is a little bit confusion. In my view, Acanthite is a instance of Mineral, Igneous>Plutonic>Exotic is a subtype of Rock. But you also could say Acanthite is a subtype of Mineral.

So, if we just create MaterialType class, could we also create 'hasMaterialSubType' property for PhysicalSample? Then, we could populate material related information of SESAR with 'hasMaterialType' and 'hasMaterialSubType' properties.

Any Comments?

sampleId top_level_classification classification xxxxxxx Mineral Acanthite xxxxxxx Mineral Almandine

xxxxxxx Rock Igneous>Plutonic>Exotic xxxxxxx Rock Metamorphic>Meta-Ultramafic

On Fri, Sep 4, 2015 at 11:32 PM, krisnadhi notifications@github.com wrote:

Then, I would model MaterialType and not Material. All those vocabulary terms like Rock, Mineral, Acanthite and Almandine are instances of MaterialTypes. If you insist on adding Material class, I would then add Rock, Mineral, Acanthite and Almandine as subclasses of Material, but not instances.

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

[krisnadhi]

hasUploadDate added

[krisnadhi]

SESAR uses the format list below to store material related information, there is a little bit confusion. In my view, Acanthite is a instance of Mineral, Igneous>Plutonic>Exotic is a subtype of Rock. But you also could say Acanthite is a subtype of Mineral.

I think the latter is more appropriate. If you say that Acanthine is an instance of Mineral, then you would essentially say that there is only one Acanthine in the world, although in reality, I would imagine there will be definitely more than one.

So, if we just create MaterialType class, could we also create 'hasMaterialSubType' property for PhysicalSample? Then, we could populate material related information of SESAR with 'hasMaterialType' and 'hasMaterialSubType' properties.

Do you want to capture the hierarchy of material types in the ontology? If yes, then we should do it using classes instead of properties, like what we do with NERC vocabulary terms.

[sparkji]

It's good. So, we still have 'hasMaterialType' property, just create voc for materialType with class and subClass, then create triple like below, is it right?

http://geolink.geosamples.org/id/sample/MGD0007VE hasMaterialType < http://schema.geolink.org/dev/voc/materialType/#32223>

On Sat, Sep 5, 2015 at 1:08 AM, krisnadhi notifications@github.com wrote:

SESAR uses the format list below to store material related information, there is a little bit confusion. In my view, Acanthite is a instance of Mineral, Igneous>Plutonic>Exotic is a subtype of Rock. But you also could say Acanthite is a subtype of Mineral.

I think the latter is more appropriate. If you say that Acanthine is an instance of Mineral, then you would essentially say that there is only one Acanthine in the world, although in reality, I would imagine there will be definitely more than one.

So, if we just create MaterialType class, could we also create 'hasMaterialSubType' property for PhysicalSample? Then, we could populate material related information of SESAR with 'hasMaterialType' and 'hasMaterialSubType' properties.

Do you want to capture the hierarchy of material types in the ontology? If yes, then we should do it using classes instead of properties, like what we do with NERC vocabulary terms.

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

[amoeba]

As per the discussion in #38, I request the following two changes to get our file formats ontology lined up:

• Change class FormatType to Format
• Change hasFormatType to from an Object Property to a DataType property, domain: Format, range: xsd:string

See the latest DataOne formats graph for how I'm using it https://github.com/ec-geolink/design/blob/master/data/dataone/formats/formats.ttl

[krisnadhi]

On Sep 5, 2015, at 1:33 AM, Peng notifications@github.com wrote:

It's good. So, we still have 'hasMaterialType' property, just create voc for materialType with class and subClass, then create triple like below, is it right?

http://geolink.geosamples.org/id/sample/MGD0007VE hasMaterialType < http://schema.geolink.org/dev/voc/materialType/#32223>

It would be something like that. For NERC vocabularies, I was able to create OWL files containing URIs minted, sort of automatically, from the NERC vocabulary server. I have no source for minting URIs for material types though. Do you have anything as such?

On Sat, Sep 5, 2015 at 1:08 AM, krisnadhi notifications@github.com wrote:

SESAR uses the format list below to store material related information, there is a little bit confusion. In my view, Acanthite is a instance of Mineral, Igneous>Plutonic>Exotic is a subtype of Rock. But you also could say Acanthite is a subtype of Mineral.

I think the latter is more appropriate. If you say that Acanthine is an instance of Mineral, then you would essentially say that there is only one Acanthine in the world, although in reality, I would imagine there will be definitely more than one.

So, if we just create MaterialType class, could we also create 'hasMaterialSubType' property for PhysicalSample? Then, we could populate material related information of SESAR with 'hasMaterialType' and 'hasMaterialSubType' properties.

Do you want to capture the hierarchy of material types in the ontology? If yes, then we should do it using classes instead of properties, like what we do with NERC vocabulary terms.

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

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

[sparkji]

IMA publishes mineral list each two month with PDF file, most minerals has unique IMA NO. like '2014-084', As a partnership with the IMA, RRUF http://rruff.info/ima/# also maintained the copy of IMA mineral list, CSV or EXCEL file could be downloaded. SESAR maintained a controlled vocabulary for Rock types.

Maybe I could create owl file for material type vocabulary, I will talk about it with Bob, let's see what will happen?

On Tue, Sep 8, 2015 at 8:41 PM, krisnadhi notifications@github.com wrote:

On Sep 5, 2015, at 1:33 AM, Peng notifications@github.com wrote:

It's good. So, we still have 'hasMaterialType' property, just create voc for materialType with class and subClass, then create triple like below, is it right?

http://geolink.geosamples.org/id/sample/MGD0007VE hasMaterialType < http://schema.geolink.org/dev/voc/materialType/#32223>

It would be something like that. For NERC vocabularies, I was able to create OWL files containing URIs minted, sort of automatically, from the NERC vocabulary server. I have no source for minting URIs for material types though. Do you have anything as such?

On Sat, Sep 5, 2015 at 1:08 AM, krisnadhi notifications@github.com wrote:

SESAR uses the format list below to store material related information, there is a little bit confusion. In my view, Acanthite is a instance of Mineral, Igneous>Plutonic>Exotic is a subtype of Rock. But you also could say Acanthite is a subtype of Mineral.

I think the latter is more appropriate. If you say that Acanthine is an instance of Mineral, then you would essentially say that there is only one Acanthine in the world, although in reality, I would imagine there will be definitely more than one.

So, if we just create MaterialType class, could we also create 'hasMaterialSubType' property for PhysicalSample? Then, we could populate material related information of SESAR with 'hasMaterialType' and 'hasMaterialSubType' properties.

Do you want to capture the hierarchy of material types in the ontology? If yes, then we should do it using classes instead of properties, like what we do with NERC vocabulary terms.

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

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

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

[krisnadhi]

IMA publishes mineral list each two month with PDF file, most minerals has unique IMA NO. like '2014-084', As a partnership with the IMA, RRUF http://rruff.info/ima/# also maintained the copy of IMA mineral list, CSV or EXCEL file could be downloaded. SESAR maintained a controlled vocabulary for Rock types.

Maybe I could create owl file for material type vocabulary, I will talk about it with Bob, let's see what will happen?

That would be a good start. You could look at how L06.owl file was implemented as an example.

[sparkji]

I talked with Bob in this morning, he agreed with you, I will create owl file for MaterialType vocabulary and maintain it. And suggest to create a new class 'MaterialType', it works like 'PlatformType' or 'FeatureType'. Also please remove the property 'hasMaterial' from main.owl, we don't need it any more.

On Tue, Sep 8, 2015 at 11:34 PM, krisnadhi notifications@github.com wrote:

On Sep 8, 2015 11:31 PM, "Peng" notifications@github.com wrote:

IMA publishes mineral list each two month with PDF file, most minerals has unique IMA NO. like '2014-084', As a partnership with the IMA, RRUF http://rruff.info/ima/# also maintained the copy of IMA mineral list, CSV or EXCEL file could be downloaded. SESAR maintained a controlled vocabulary for Rock types.

Maybe I could create owl file for material type vocabulary, I will talk about it with Bob, let's see what will happen?

That would be a good start. You could look at how L06.owl file was implemented as an example.

On Tue, Sep 8, 2015 at 8:41 PM, krisnadhi notifications@github.com wrote:

On Sep 5, 2015, at 1:33 AM, Peng notifications@github.com wrote:

It's good. So, we still have 'hasMaterialType' property, just create voc for materialType with class and subClass, then create triple like below, is it right?

http://geolink.geosamples.org/id/sample/MGD0007VE hasMaterialType < http://schema.geolink.org/dev/voc/materialType/#32223>

It would be something like that. For NERC vocabularies, I was able to create OWL files containing URIs minted, sort of automatically, from the NERC vocabulary server. I have no source for minting URIs for material types though. Do you have anything as such?

On Sat, Sep 5, 2015 at 1:08 AM, krisnadhi notifications@github.com wrote:

SESAR uses the format list below to store material related information, there is a little bit confusion. In my view, Acanthite is a instance of Mineral, Igneous>Plutonic>Exotic is a subtype of Rock. But you also could say Acanthite is a subtype of Mineral.

I think the latter is more appropriate. If you say that Acanthine is an instance of Mineral, then you would essentially say that there is only one Acanthine in the world, although in reality, I would imagine there will be definitely more than one.

So, if we just create MaterialType class, could we also create 'hasMaterialSubType' property for PhysicalSample? Then, we could populate material related information of SESAR with 'hasMaterialType' and 'hasMaterialSubType' properties.

Do you want to capture the hierarchy of material types in the ontology? If yes, then we should do it using classes instead of properties, like what we do with NERC vocabulary terms.

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

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

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

— Reply to this email directly or view it on GitHub.

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

[krisnadhi]

But you would still need a property, say hasFormat, to state the format of a DigitalObject, wouldn't you?

As per the discussion in #38, I request the following two changes to get our file formats ontology lined up:

• Change class FormatType to Format
• Change hasFormatType to from an Object Property to a DataType property, domain: Format, range: xsd:string

See the latest DataOne formats graph for how I'm using it https://github.com/ec-geolink/design/blob/master/data/dataone/formats/formats.ttl