Are string data values part of the value specification framework?

obi-ontology / obi

The Ontology for Biomedical Investigations

http://obi-ontology.org

Creative Commons Attribution 4.0 International

75 stars 25 forks source link

Are string data values part of the value specification framework? #985

Open turbomam opened 5 years ago

turbomam commented 5 years ago

About a week ago, @jamesaoverton pointed out that some textual data might often be better modeled as something other than specified values of value specifications.

Say I have a table with two columns

identifiers for health care encounters
textual representations of drugs that were prescribed as part of those encounter processes.

When reified, one fragment will look like this:

HCE1 a health care encounter HCE1 has output DP1 DP1 a drug prescription (PDRO_0000024, a kind of document)

Let's say that one of the prescription strings is "500 mg Tylenol po tab". Some process (like search + machine learning) might classify the prescription texts, leading to statements like

DP1 mentions http://purl.bioontology.org/ontology/RXNORM/209459

Still, one might want to retain the textual representation of the prescription as provenance.

A value specification is

An information content entity that specifies a value within a classification scheme or on a quantitative scale.

Should the value specification framework be used to tie the RxNorm drug to the prescription, as a values within a classification scheme, instead of mentions? (Either way it's punning.) Or should "500 mg Tylenol po tab" be a specified value? It seems more like a free-form string than a value withing a categorical scheme.

Should new properties be created within the application ontology for situations like this? With how much granularity? (has provenance string vs has prescription string?) As datatype properties or annotation properties?

In some cases, it might be necessary to tie two strings to an instance in support of one of that instance's object relations, so that might justify the more granular property style. For example, a diagnosis (OGMS_0000073) instance might "end up" mentioning a code from one of the ICDs like http://purl.bioontology.org/ontology/ICD10CM/V91.07. If the ICD version (ICD10CM) and the code itself (V91.07) appear in the data table as separate columns, they could be joined to the diagnosis instance with two properties, or they could be concatenated together.

The concatenation approach might be more tricky if the two strings need to be processed independently. An allele information instance (OBI_0001352) might be tied to two different strings from the database: one for the level of wild-type-zygosity (0, 1 or 2), and one with the symbol for identifier for a gene (like ENSG00000151577). The rues engine would then examine the two types of strings (based on the properties that join them to the allele information) and conclude that the allele information mentions gene http://rdf.ebi.ac.uk/resource/ensembl/ENSG00000151577 and a semantic term for the zygosity level from an application ontology. In this case, the two strings should probably be bound to the allele information with properties like has zygosity string and has gene identifier string.

jamesaoverton commented 5 years ago

Discussed on the 2018-11-12 call. Bjoern and James prefer a "prescription" class somewhere under ICE (maybe under "document"). But there's a more basic problem that we don't have a good predicate for linking an instance of one of these classes to is string representation. We should consider adding "has string representation" as a datatype property, or something, with domain ICE. There are advantages to using a single property consistently.

This is another case where it would be good to have detailed proposal to discuss. This issue is a good start.

bpeters42 commented 5 years ago

It seems like we should have a general set of annotation properties, connecting an ICE to a string / number / etc.

has_representation has_string_representation has_numeric_representation has_electronic_document_representation (maybe; I was thinking about pdfs)

These relations should be applicable to ICEs beyond value specification (such as in Mark's case of a prescription)

On Mon, Nov 12, 2018 at 10:02 AM James A. Overton notifications@github.com wrote:

Discussed on the 2018-11-12 call. Bjoern and James prefer a "prescription" class somewhere under ICE (maybe under "document"). But there's a more basic problem that we don't have a good predicate for linking an instance of one of these classes to is string representation. We should consider adding "has string representation" as a datatype property, or something, with domain ICE. There are advantages to using a single property consistently.

This is another case where it would be good to have detailed proposal to discuss. This issue is a good start.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/obi-ontology/obi/issues/985#issuecomment-437975122, or mute the thread https://github.com/notifications/unsubscribe-auth/ANN9InHhhr-dHiRe5RX-vWKUvRNcZ2xFks5uube5gaJpZM4YZ_fp .

-- Bjoern Peters Professor La Jolla Institute for Allergy and Immunology 9420 Athena Circle La Jolla, CA 92037, USA Tel: 858/752-6914 Fax: 858/752-6987 http://www.liai.org/pages/faculty-peters

ddooley commented 5 years ago

So value specification's 'has specified value' allows strings - 'textual representations' ("intended to link a value found in e.g. a database column of 'M' (the literal) to an instance of a value specification class." I have proposed in the new draft documentation that we can use 'specifies value of' object property to connect such a value to the categorical it maps to, e.g. "male" PATO_0000384, and that in fact that latter relation is all that needs recording, leaving the textual value optional unless there are no ontology categories to point to.

I see currently 'value specification' is intended to constrain value to that chosen from a scale, setting up further value-level analysis axiom tests about experimental variables and other i/o.

But can't we loosen this up a bit. Can the 'has specified value' allow more than a categorical textual representation?

Allow it to be an identifier (centrally registered or otherwise); These may not be categorical in the strict sense insofar as the namespace may be large or open-ended). Both string and numerical values can be act as identifiers. Identifiers can be compared for match, and this presumably allows tying together information that otherwise would require external processing to associate. What is important is that in saying what class of identifier something is, this enables data exchange with other graphs that have that same identifier, without assuming someone has gone through the work of tying the graphs together. As well, validation axioms can be imposed on string and numeric identifiers e.g. Canada postal code = "ANA NAN" alphanumeric format using OWL string regular expression pattern. Postal codes are very useful centrally registered symbols for correlation etc.
allow it to be opaque - to have semantics that is only accessible via declaration of what type of value specification it is (postal code etc), or by semantics that appears only after some other translation/parsing. This can be viewed as pre-cursor data that may be helpful in provenance. Some would argue this should then be just an annotation?

Other ontologies have 'has value' data property with anything possible within rdf/xml data types at target end. I see the opportunity for OBI 'value specification' to be the vehicle that allows us to constrain (by rdf/xml data type, length, string pattern, precision etc.) what the 'has specified value' is, and what it is about via 'specifies value of', which can line up perfectly with datum aboutness, thus achieving data interoperability.

ddooley commented 5 years ago

Alternatives: Instead of allowing value specifications to point to identifiers as open-ended string or numeric values, we could use patterns like this:

data_lee_has_value

But I think this means we have to add has value to OBI from somewhere. Seems like RO doesn't have it. Or we broaden has specified value so it can have a domain other than value specification.

If we go that route, what advice to give folks about selecting object relations that bind the subject entity to the ICE that has the entity for its aboutness. I threw up denotes and location of examples there as talking points.

Ps. I see OWL has owl:hasValue but that OWL Lite is precluded from having this (https://www.w3.org/TR/owl-ref/ 3.1.2.1.3). Does that ban it from being used in OBI?

bpeters42 commented 5 years ago

I cannot follow this at all. Is it saying that an instance of a street address inheres in a person?

I am all for creating shortcut relations, but they need to be marked as such. So I can completely see why we want to have a "has_home_address" relationship as a short cut, but we can't overload our main relationships like this, but maybe I am missing something.

I would think there would be something like class: personal postal address is_a value specification personal postal address has_part some (denotes some site) personal postal address has_part some (denotes some person)

Then there is different types of personal postal addresses, such as 'home address', 'business address', 'vacation address'. They all have the same structure, but they indicate that there are different relations between the site and the person etc.

Just throwing this out there, not sure how helpful it is, but I am afraid there is confusion or disagreement on some fundamental things of how information vs. reality works.

On Thu, Jan 31, 2019 at 9:59 AM Damion Dooley notifications@github.com wrote:

Alternatives: Instead of allowing value specifications to point to identifiers as open-ended string or numeric values, we could use patterns like this:

https://camo.githubusercontent.com/f4d153873813024e81a2acb19228ea66298de1ad/68747470733a2f2f64646f6f6c65792e6769746875622e696f2f6173736574732f696d616765732f646f63732f646174615f6c65655f6861735f76616c75652e706e67 [image: data_lee_has_value] https://user-images.githubusercontent.com/4000582/52074358-86b94680-253e-11e9-8b95-3f53ba0a19b1.png

But I think this means we have to add has value to OBI from somewhere. Seems like RO doesn't have it. Or we broaden has specified value so it can have a domain other than value specification.

If we go that route, what advice to give folks about selecting object relations that bind the subject entity to the ICE that has the entity for its aboutness. I threw up a has location example there.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/obi-ontology/obi/issues/985#issuecomment-459443202, or mute the thread https://github.com/notifications/unsubscribe-auth/ANN9IhAV80aGM0O_dkFOQaFxo8YLS06hks5vIy8EgaJpZM4YZ_fp .

-- Bjoern Peters Professor La Jolla Institute for Allergy and Immunology 9420 Athena Circle La Jolla, CA 92037, USA Tel: 858/752-6914 Fax: 858/752-6987 http://www.liai.org/pages/faculty-peters

ddooley commented 5 years ago

I'd revised the diagram today after seeing it had its arrows/relations wrong - it should show location of rather than inheres in. Hopefully a visit to https://github.com/obi-ontology/obi/issues/985 resolves that?! But perhaps that's overloading 'location of' !

A) The fundamental issue is that either value specifications need to be allowed to have values that are not categorical or in a scale, which I'm in favour of (we then revise its definition and make some subclasses of value specification that are only scalar or categorical etc. and can then do "class: personal postal address is_a value specification" which I like very much.)

B) Or we introduce a has value data property that operates outside of value specification ... Was this in line with what you were thinking James & Mark? That is what the diagram above was trying to do.

C) Or we loosen up has specified value so that its domain isn't just value specification, so we don't have to introduce has value to OBI, but it accomplishes B).

bpeters42 commented 5 years ago

I thought we had long ago agreed on A). I might be out of the loop.

On Thu, Jan 31, 2019 at 5:36 PM Damion Dooley notifications@github.com wrote:

I'd revised the diagram today after seeing it had its arrows/relations wrong - it should show location of rather than inheres in. Hopefully a visit to #985 https://github.com/obi-ontology/obi/issues/985 resolves that?! But perhaps that's overloading 'location of' !

A) The fundamental issue is that either value specifications need to be allowed to have values that are not categorical or in a scale, which I'm in favour of (we then revise its definition and make some subclasses of value specification that are only scalar or categorical etc. and can then do "class: personal postal address is_a value specification" which I like very much.)

B) Or we introduce a has value data property that operates outside of value specification ... Was this in line with what you were thinking James & Mark? That is what the diagram above was trying to do.

C) Or we loosen up has specified value so that its domain isn't just value specification, so we don't have to introduce has value to OBI, but it accomplishes B).

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/obi-ontology/obi/issues/985#issuecomment-459573529, or mute the thread https://github.com/notifications/unsubscribe-auth/ANN9ImK0VLHn5V42UYXL421TAzrh0QRSks5vI5opgaJpZM4YZ_fp .

-- Bjoern Peters Professor La Jolla Institute for Allergy and Immunology 9420 Athena Circle La Jolla, CA 92037, USA Tel: 858/752-6914 Fax: 858/752-6987 http://www.liai.org/pages/faculty-peters

ddooley commented 5 years ago

I recall the ok to add some more value specification subtypes but I think the string value specification class was in question because of the existing vs definition that disallows it. If that was decided to be ok then I will submit a revised vs definition. I have to admit I've forgotten...

But still this leaves James' and perhaps others desire for a way - shown in diagram? - to have a value expressed without having a value specification involved, so simple strings, unit-less numbers could be done that way. Having a value connected directly to an ICE instance related to an entity being described. If that's already agreed on too then I've forgotten whether we were going to do that via B or C?

bpeters42 commented 5 years ago

I went through the history of this discussion, and would like to get it back to the starting point, and in that process point out where I think we might have diverged.

When a blogger writes an article on his laptop, publishes it on his blog, where it gets picked up by an aggregator site, printed out by someone on paper etc, all of these are different concretizations of the same instance of an information content entity. When I weigh a mouse, and get a result of 20 grams displayed on the scale, which I write in a notebook along with some identifier for the mouse and a date, then copy that an Excel spreadsheet, and send the results at the end of the week to the data manager by email, who enters it into a database of mouse weights, then all the variations of "20g" are different concretizations of the same instance of an information content entity, including if one there are differences in spacing or spelling out grams or just using g.

The difference between a quantitative value specification and a blog article is the subtype of ICE. But there would be value to enable at the high level to link an instance of an ICE with a possible electronic representation through an annotation property.

That is where my suggestion came in to use annotation properties between instances of ICEs and strings and other variables such as

has_representation has_string_representation has_numeric_representation has_electronic_document_representation

Now when we talk about value specifications, what makes them different is that we can encounter them in different contexts, and compare them. So I can compare the mouse weight I have recorded to a weight I recorded 1 month earlier, and say which one is greater. And I can do that for any other mass value specification I encounter that are recorded on the same scale, saying that the reported weight of Abraham Lincoln is great than that of my mouse. So I can make statements about reality (the mass quality inhering in the mouse over time and Abe), that are straightforward to compute on value specifications. I can compare tumor grading results pre- and post- therapy, and say if the tumor is more or less clinically severe after a treatment. I can aggregate such results and make statistical statements about the likelihood of tumor regression with a certain treatment. No such obvious comparisons and connections to reality are possible when having blog articles.

That is why the 'has value' relation for a value specification is more specific than the 'has representation' relation proposed above for an ICE.

So in the example above, I weigh a mouse, the information is recorded in different places, meaning there are different concretizations of the same instance of a mass value measurement, which has as a part different concretizations of a mass value specification X.

So there can be many 'has representation' annotation properties, such as:

X has_representation "20g" X has_representation "20 g" X has_representation "20 grams" X has_representation "20 GRAMS" ... and all kinds of variations thereof in character encoding, tiff files, hexadecimal numbers, writing on paper etc.

But there is a single precise way how X is represented as a value specification that allows for exact comparisons with value specifications of the same kind: X has_unit_label "gram" X has_scalar_value 20

This took me way too long, but also clarified my thinking. I hope we can discuss more Monday. An interesting sub-study of this is unit conversions, but I think we need to come to agreement with the above first.

ddooley commented 5 years ago

I see the value of having a "has_representation" annotation (always an xsd:string I presume even if it is representing numeric content) which records a kind of undigested data, and which requires further parsing to break into an equivalent value specification.

And, in contrast, "has specified value" has as its object a value which cannot be parsed any further; we've reached representational atomicity.

bpeters42 commented 5 years ago

I love your phrase 'representational atomicity'. That cuts to the core of what I was trying to say in a page of writing :)

In terms of "has_representation" always pointing to xsd:string, I thought it would be nice to allow for e.g. a .pdf file to be pointed to or other such things that go beyond xsd:string. For me, in an ideal world, 'has_representation' would point to a very generic specification of digital information, spelling out both format and content. but we can start with strings that are most practical.

ddooley commented 5 years ago

Ok on "has_representation" pointing to other things that have format and content.

We should explore composite value expressions like your "personal postal address" that could have city, street, etc. elements. Rifting off your example, I'm trying to separate the value spec. from an expression of what it is about via an ICE.

class: postal address
     is_a ICE
     denotes exactly 1 (site and 'has role' some 'postal service role')

class: personal postal address 
     is_a ICE
     denotes exactly 1 `postal address`
     denotes some person

class: personal postal address VS
    is_a "string value specification"
    specifies value of some 'personal postal address'

more napkin design:

class: home
     is_a site
     'has role' some 'home role'

class: home postal address 
    is_a personal postal address
    denotes exactly 1 home

class: home postal address value specification
    is_a 'string value specification'
    'specifies value of' some 'home postal address'

ddooley commented 5 years ago

The latest discussion on "has_representation" is about deciding what the data property labels should be, and a bit about their semantics, and where they should go - OBI, IAO, or ...? Below are the proposed choices of data property names, as well as some further semantic distinctions that could be made which specify the form of the content beyond the xsd datatype constraint, if any. These relations point to data which is not (yet) declared categorical, or scalar and so cannot fit in a "value specification". It includes for example, counts, string representations of numbers like "20g", and other unit-less numbers, alphanumeric identifiers, dates, street addresses, postal codes, and drug dosage text that could potentially be parsed.

One outstanding issue is for scalar data represented as a string, e.g. "20 g". Do we create a "has numeric value as string" relation for this? Or do we use "has numeric value" and back away from fixing the range of this data property to "xsd:real", so that strings are allowed?

has rdfs:Literal representation // range xsd:Literal
   has xsd:string representation // range xsd:string;
   has xsd:integer representation // range xsd:integer
   ... etc.

has rdfs:Literal data type value // range xsd:Literal
   … etc.

has rdfs:Literal value // range xsd:Literal
    has alphanumeric value // range xsd:string; not necessarily linguistically parsable
        has linguistic value // range xsd:string ; Textual content -word, phrase, sentence(S) that is linguistically parsable in some language.
    has datetime value // range xsd:dateTime or xsd:dateTimeStamp
    has numeric value // range owl:real (covers subordinate xsd datatypes like decimal, float, int)
        has decimal value // range xsd:decimal
        has integer value // range xsd:integer

Feedback appreciated!

bpeters42 commented 5 years ago

I will try to make my point once more why I think having 'value' in the name of the property is not a good idea, because it in my mind makes it easy to get confused about the 'representation' vs. the 'value specification' aspects of an information content entity. I may very well be wrong about this, as I could clearly sense that no-one on the call seemed to share my concerns. But then I would ask people to speak up, and let me know where I am wrong. More importantly, I feel that the seeming dispute about labels points to a deeper disconnect about modeling in general.

Case in point, Damion's email, asks: "One outstanding issue is for scalar data represented as a string, e.g. "20 g". Do we create a "has numeric value as string" relation for this? Or do we use "has numeric value" and back away from fixing the range of this data property to "xsd:real", so that strings are allowed?"

Either I am not getting something, or this is the conflation of representation vs. value parsing that I was trying to avoid. To me it is obvious that "20 g" is a string. And the moment you are saying that what it is meant to encode is a number and a unit, that is the value specification.

to spell it out, when I find in a table column titled "Mass" a string "20 g", I thought we want to say that

X instance_of (scalar value specification and specifies_value_of some mass) X has xsd:string representation "20 g" X has_specified_numeric_value 20 X has_measurement_unit_label gram

In my mind, if in the above we call the relation 'has xsd:string representation' instead as 'has alphanumeric value', it will be really hard to keep the two apart. Reading back through Damions material from today, there might be a deeper disconnect.

These discussions are hard. respect for everyone's patience.

Bjoern

On Mon, Feb 11, 2019 at 6:31 PM Damion Dooley notifications@github.com wrote:

The latest discussion on "has_representation" is about deciding what the data property labels should be, and a bit about their semantics, and where they should go - OBI, IAO, or ...? Below are the proposed choices of data property names, as well as some further semantic distinctions that could be made which specify the form of the content beyond the xsd datatype constraint, if any. These relations point to data which is not (yet) declared categorical, or scalar and so cannot fit in a "value specification". It includes counts, string representations of numbers like "20g", and other unit-less numbers, alphanumeric identifiers, dates, street addresses and postal codes that could potentially be parsed.

One outstanding issue is for scalar data represented as a string, e.g. "20 g". Do we create a "has numeric value as string" relation for this? Or do we use "has numeric value" and back away from fixing the range of this data property to "xsd:real", so that strings are allowed?

has rdfs:Literal representation

has xsd:string representation

has xsd:integer representation

OR

has rdfs:Literal data type value

…

OR

has rdfs:Literal value
has alphanumeric value // range xsd:string; // not necessarily linguistically parsable

    has linguistic value // range xsd:string ; Textual content is linguistically parsable in some language.

has datetime value // range xsd:dateTime or xsd:dateTimeStamp

has numeric value // range owl:real (covers subordinate xsd datatypes like decimal, float, int)

    has decimal value // range owl:decimal

    has integer value // range owl:integer
Feedback appreciated!

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/obi-ontology/obi/issues/985#issuecomment-462589397, or mute the thread https://github.com/notifications/unsubscribe-auth/ANN9IpBadrob_NOPKQ5cOHu-YX-V-7Jdks5vMieOgaJpZM4YZ_fp .

-- Bjoern Peters Professor La Jolla Institute for Allergy and Immunology 9420 Athena Circle La Jolla, CA 92037, USA Tel: 858/752-6914 Fax: 858/752-6987 http://www.liai.org/pages/faculty-peters

ddooley commented 5 years ago

Thanks for bringing more clarity Bjoern. Perhaps historically people will thank us for mulling over this so much!

I meant to frame the "20g" example in advance of any potential parsing of it into a value specification. E.g. I can see each number in a particular spreadsheet column is stored as a string with its unit, so was thinking one would want to say each column cell is a string representation of a number.

I now see the wisdom of having a data property label convey nothing more than the xsd:datatype that its object has; object relations can handle the rest of the semantics. So I'd drop the alphanumeric & linguistic data properties for this reason.

About the label, the string case is a bit unique in that inside the string there really is a representation in some parseable language. So the use of "representation" makes sense in "x has xsd:string representation "20 g"!

However, the other xsd:datatypes are much more strict, less easy to see that they are representations in some yet-to-be-parsed language; rather they are atomic values (vis-a-vis OWL) unambiguously structured entirely by their datatypes.

X 'has xsd:integer value' "102"^^xsd:integer

And xsd:dateTime falls in this category too, though it could have a dual role as a VS scalar too?

X 'has xsd:dateTime value' "1992-01-01T00:00:12"^^xsd:dateTime

But I'm not hard core about this. Others ready to opine?

ddooley commented 5 years ago

I just remembered - what to do about "has_electronic_document_representation" ? This would now be adding too much semantics to a "has xsd:string representation"? Or would we add a "has xsd:anyURI value" data property for this?

bpeters42 commented 5 years ago

I thought we had already said that we were going for URIs (maybe a bit more specific than xsd:anyURIvalue, and enforce that they resolve over http). But we can also delay that.

In my world, we annotate papers, which includes stating that the height of bars a and b in Figure X represents the average weight of mice in my experiment before and after treatment. Which I believe to be analogous to string representation of numbers discussed before.

Keep it on the back burner? If we just solve strings, we are already much better than we were :)

But also

On Tue, Feb 12, 2019 at 7:51 AM Damion Dooley notifications@github.com wrote:

I just remembered - what to do about "has_electronic_document_representation" ? This would now be adding too much semantics to a "has xsd:string representation"? Or would we add a "has xsd:anyURI value" data property for this?

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/obi-ontology/obi/issues/985#issuecomment-462813596, or mute the thread https://github.com/notifications/unsubscribe-auth/ANN9IixFkSJKe1Mh3HOew9aF4M4Mfy9xks5vMuLwgaJpZM4YZ_fp .

-- Bjoern Peters Professor La Jolla Institute for Allergy and Immunology 9420 Athena Circle La Jolla, CA 92037, USA Tel: 858/752-6914 Fax: 858/752-6987 http://www.liai.org/pages/faculty-peters

ddooley commented 5 years ago

Ok, I've modified DRAFT docs on https://obi-ontology.ontodev.com/docs/data-properties/ to include xsd:anyURI option. I'm pitching one more content organization change there, to have 4 sections for choosing the right data property setup:

OWL RDF/XML datatype compatible
String representation compatible (technically a subset of the above?)
Scalar value specification compatible
Categorical value specification compatible

Sound good?

bpeters42 commented 5 years ago

In my mind, these two:

Scalar value specification compatible
Categorical value specification compatible

are completely different. If we are still not agreeing to that, then there is still discrepancy of our understanding of 'representation' vs. 'has_value"

On Wed, Feb 13, 2019 at 12:50 AM Damion Dooley notifications@github.com wrote:

Ok, I've modified docs on https://obi-ontology.ontodev.com/docs/data-properties/ to include xsd:anyURI option. I'm pitching one more content organization change there, to have 3 sections for choosing the right data property setup:

OWL RDF/XML datatype compatible

String representation compatible (technically a subset of the above?)

Scalar value specification compatible

Categorical value specification compatible

Sound good?

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/obi-ontology/obi/issues/985#issuecomment-463111686, or mute the thread https://github.com/notifications/unsubscribe-auth/ANN9IiCIahn6wPaRd5Y3RXnDJzuWS5XYks5vM9HEgaJpZM4YZ_fp .

-- Bjoern Peters Professor La Jolla Institute for Allergy and Immunology 9420 Athena Circle La Jolla, CA 92037, USA Tel: 858/752-6914 Fax: 858/752-6987 http://www.liai.org/pages/faculty-peters

ddooley commented 5 years ago

I agree they're pretty different. I was listing them straight from OBI value specification subclasses. I figured listing them individually and at the same level would enable people to see the choices before them better.

ddooley commented 5 years ago

I mean to convey: the four sections listed will cover all the different kinds of datum value.

ddooley commented 5 years ago

Is there general agreement that OBI can just use “has specified value” rather than introducing other new data properties? Instead the focus can be on creating value specifications to declare Boolean, datetime etc. classes of value specification. VS classes can even set expected xsd:datatype constraints that way if they want via " 'has specified value' some xsd:boolean" etc. at class level.

Various value specification classes will be described in individual issues so we can pickup discussion in a more focused way.

I will put in a new term request for "has textual representation" separately.

So we can close this thread?

bpeters42 commented 5 years ago

There is me agreeing with this, and we have the general design preference to add as few as possible properties, so I think this should be uncontroversial. Objections can be discussed in the Monday call, otherwise let's definitely close this.

On Sat, Jun 1, 2019 at 11:54 AM Damion Dooley notifications@github.com wrote:

Is there general agreement that OBI can just use “has specified value” rather than introducing other new data properties? Instead the focus can be on creating value specifications to declare Boolean, datetime etc. classes of value specification. VS classes can even set expected xsd:datatype constraints that way if they want via " 'has specified value' some xsd:boolean" etc. at class level.

Various value specification classes will be described in individual issues so we can pickup discussion in a more focused way.

I will put in a new term request for "has textual representation" separately.

So we can close this thread?

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/obi-ontology/obi/issues/985?email_source=notifications&email_token=ADJX2IVHK6UTZPZ6UT2T2RLPYLAWBA5CNFSM4GDH67U2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODWXGQYY#issuecomment-497969251, or mute the thread https://github.com/notifications/unsubscribe-auth/ADJX2IRXT7GB4S54WAYGX7DPYLAWBANCNFSM4GDH67UQ .

-- Bjoern Peters Professor La Jolla Institute for Allergy and Immunology 9420 Athena Circle La Jolla, CA 92037, USA Tel: 858/752-6914 Fax: 858/752-6987 http://www.liai.org/pages/faculty-peters