Aspects are behaviors that can be configured above the ontologies concept, their main goal is to optimize the data to enforce their potential.
We wanted at first restructure some ontologies to add specific behavior depending on class inheritance but since ontologies are standard we are not in a position to modifiy them by any means, that is how we came with the aspect idea.
Still, aspects could have been hardcoded into Ziggy in order to optimize some ontologies but we wanted the optimisations to be configurable in a declarative way.
There is currently two available type of aspect :
TimeSeries : Each time a datatype property is updated for a projection its data is stored into an InfluxDB Time Series which enable TimeSeries request type (mean, avg over a given period of time) onto the projection datatype property
GeoSpatial : Enhance a datatype property designed to store geo spatial data and make it available for specific geospatial operator
We have other idea in minds such as :
INDEXED : Add an index over a datatype property to make research faster
EMBEDDED : Enable anonymous projection to be created for a given Object Property
VIRTUAL : Create a projection without an associated thing
Those are not implemented yet, as always, we do apologize ¯_(ツ)_/¯
To store GeoSpatial data we rely on GeoJson (You may find the reference here : http://geojson.org/ ). Note that there is some schenanigans about the way we manipulate GeoJson data, the semantic world don't know what JSON is so we store those as string in Turtle. Soon enough we will make it fully transparent to you in JSON, it's in the planning.
Right now you need to escape the Geo Json payload as a String as such :
Accepted :
sens-obs:point_C1692
a wgs84:Point ;
wgs84:alt "1995"^^xsd:float ;
wgs84:lat "41.6570"^^xsd:float ;
wgs84:long "-78.900"^^xsd:float ;
<http://www.opengis.net/gml/pos/linestring> "{\"type\": \"LineString\",\"coordinates\": [[-1.6281831, 41.6570], [-1.6296897, 48.1262971], [-1.6281831, 48.126252]]}"^^xsd:string .
Rejected:
sens-obs:point_C1692
a wgs84:Point ;
wgs84:alt "1995"^^xsd:float ;
wgs84:lat "41.6570"^^xsd:float ;
wgs84:long "-78.900"^^xsd:float ;
<http://www.opengis.net/gml/pos/linestring> "{"type": "LineString","coordinates": [[-1.6281831, 41.6570], [-1.6296897, 48.1262971], [-1.6281831, 48.126252]]}"^^xsd:string .
About the coordinates : in the coordinates array its [ 'longitude, latitude ]
This is an important thing to notice because if you take the data from Google, their coordinates [ latitude, 'longitude ] ( you know what they say ' Meh, we do what we want, we don't care, blah blah blah... ' ).
By default there is three datatype property which are designed to store GeoJson data into Ziggy:
A datatype property enhanced with a Geo Spatial aspect must be specialized toward either:
The last three ones (MULTIPOINT, MULTILINESTRING, MULTIPOLYGON) will be available later, sorry again ¯_(ツ)_/¯ (one day people will think we're canadians).
You MUST specialize the datatype property into one specific type because there is no generic spatial index available into OrientDB, at least at this moment.
Here is how a GeoJson Spatial aspect works, it simply takes the data of the original datatype property as string and convert them to a specific geometric structure on which we apply geo index defined in the Lucene engine (it is a plugin for OrientDB).
Also, for each of the enhanced datatype property we create 4 additionnal properties :
Those are metadata inaccessible from the exterior, they hold, for the associated geometry, the coordinates of a bounding box to apply for QuadTree tile at level 17.
You may want more information about QuadTree tile, here are some references :
All of these additionnal metadata for this datatype property allows it to be used with GeoSpatial operators for /projection/find request and to access projection using the /tile API.