ISSUE-110 Add additional types of variables to repr.ttl

[lewismc]

This PR addresses #110

I also noticed that data was missing for representations of dimensions e.g. 1D, 2D and 3D which had all been changed to D somehow...

[lewismc]

Any comments @ESIPFed/semtech

[carueda]

I would have to review the whole SWEET approach in general, but at least in this case, it seems to me that repr:1D, repr:2D and repr:3D should be instances and not classes themselves: you wouldn't be creating instances of repr:1D for example.

Perhaps something like this would be more appropriate?

repr:1D rdf:type repr:Representation ,
                       [ rdf:type owl:Restriction ;
                         owl:onProperty mrela:hasDimension ;
                         owl:hasValue 1
                       ] .

[cmungall]

First a pragmatic question: would this affect any existing infrastructure that uses sweet and hardcodes certain assumptions about everything being classes, and subClassOf being the main linking predicate? For example, would this cause 1D to drop out of some ontology browser displays?

But I think we also need a definition of 1D and some use cases showing how it gets used. This is where an upper ontology can help. While I think BFO can be a little abstruse at times, it does provide a framework for distinguishing things like variables vs projections in space etc. Going along with this, I think 1D is too short a name for a class, because I don't know from the name what it is. Is it literally the value for a unit "dimension" or can it be used for a 1D entity (e.g a conceptual line between Glasgow and Edinburgh)...?

[graybeal]

SWEET has many cases where "what was meant" can not be discerned from the content (witness the discussion of 'sample'); I think this is one of those. In which case it's on us to figure out what would be most useful.

I believe that a 1D representation in SWEET is a class descriptor for all the 1D lines in the world (at least, all the 1D lines that follow the 'Representation' class constraints). I do not think these should be individuals in SWEET.

I agree that '1D' is a poor name. I would like to see it deprecated in favor of something like 'one-dimensional representation', appropriately camel-cased and de-spaced and de-hyphened as needed to match SWEET.

And yes, changing anything to an individual will mean certain repositories ( looking at you BioPortal) will no longer present it in the UI. But I don't think that should affect the decision-making process, and it didn't affect the recommendation I made above.

[lewismc]

Let me address these issues and update the PR folks. We can take it from there. Thanks for the input.

[lewismc]

In addition to providing the additional types of variable and accomodating descriptions for all variables now included within repr.ttl, I updated the PR to essentially deprecate the 1D, 2D and 3D classes replacing them with Classes bearing the string literal name.
I have not yet addressed the instances vs classes issue highlighted by @carueda. I am going to hold off on the provision of an rdfs:comment before we address that issue.

[lewismc]

I do want to note that the Class naming issue we've identified above is more widespread across SWEET.
Take the following

http://sweetontology.net/reprSpaceGeometry/GeometricalObject_0D
http://sweetontology.net/reprSpaceGeometry/GeometricalObject_1D
http://sweetontology.net/reprSpaceGeometry/GeometricalObject_2D
http://sweetontology.net/reprSpaceGeometry/GeometricalObject_3D
http://sweetontology.net/reprDataModel/Swath_2D
http://sweetontology.net/reprDataModel/Swath_3D
http://sweetontology.net/reprSpaceGeometry3D
http://sweetontology.net/reprMath/Vector_3D
http://sweetontology.net/relaSpace/hasCommon2DBorderWith

There is more work to be done here...

[graybeal]

I'm not sure it's as bad as all that. If you accept the theory that these are types of representations, then there is no need to change the classes to individuals.

And in this case the '2D' or '3D' or whatever does not have to be spelled out IMHO, because the context is much more apparent. The problem with standalone '1D', '2D', etc. is that it omitted the fact these were representations. So a better suggestion than my previous is Representation_1D, which would match these other forms.

Except SpaceGeometry3D, which clearly needs an underscore before 3D.

[lewismc]

OK @graybeal I'll update based on this.

[carueda]

@lewismc As John notes, those do look like classes. Take for example GeometricalObject_1D; it makes sense to have statements like ex:fooObj a GeometricalObject_1D, ex:baz a GeometricalObject_1D, etc.

By contrast, as already noted above, one wouldn't be creating instances of repr:1D . The point with repr:0D, repr:1D, ..., is that they already represent the concrete concepts of 0-dimensionality, 1-dimensionality, .... With the repr:Dimensionality class already in SWEET, we may want to consider introducing these concrete dimensionality concepts with statements like repr:D0 a repr:Dimensionality, repr:D1 a repr:Dimensionality (along with any additional statements --eg., restrictions-- to further characterize such concept).

[lewismc]

OK @graybeal I've updated based on your suggestions. I wanted to make the following reply however

Except SpaceGeometry3D, which clearly needs an underscore before 3D.

This is a file IRI not a Class IRI. I would like to suggest that we limit the impact of changing the file IRI by adhering to the following

• FIle IRI's follow UpperCamelCaseWithNoUnderScore
• Class IRI's follow UpperCamelCaseWithUnderscoresFor_Numbers

What do you think?

[lewismc]

@carueda thanks for the comments. I think we should address this in a separate ticket to keep things separate.

[lewismc]

Tempted to close this ticked off and to resubmit the suggested fix in a separate PR... however I want to clarify what our approach is to the several issues mentioned above.