Re: QB4ST example

Thanks, Rob

I quite like this ontology. I think we should incorporate into our
(ANU-LED) example, and merge it into the note. It does a good job of
factoring out the abstract "coverage" bits of a datacube description of a
coverage.

You mentioned earlier that you were planning to add time dimensions also;
that would be good.

It's also missing something that you mentioned during one of the meetings,
and that I think would be valuable - some way to specify the domain and
maybe the range of a coverage. This could be as simple as a :maxValue and
:minValue property for the qb4st:CoordDimension. Although if dimensions
specifications are supposed to be reusable, they may need to go somewhere
else.

Other than that, I think it has, if anything, too much stuff. I don't
think SpatialDimensionComponentSpecification
and SpatialMeasureComponentSpecification are necessary, and I don't
think AnyNumber
is either - I think it might be better to leave the ranges unspecified.
Likewise, I'm not sure that CoordDimension adds any real value on top of
SpatialDimension. Latitude and longitude properties I'm unsure about -
those are probably common enough to justify having them in a general
ontology like this? But the x,y,z properties are questionable - the very
definition of x,y,z is very malleable and depends on the CRS, so I'm not
sure there's any benefit from defining them; we would expect users to
define those dimensions themselves with reference to whatever CRS they are
using.

Lastly, I'm not too comfortable with stating things about geo: terms; I
would prefer instead that the user define something like:

led:lat a qb:MeasureProperty ;
    rdfs:subPropertyOf geo:lat, qb4st:latMeasure .

or, even better, to use a definition from so: once those exist.


I'll start reworking our example to use QB4ST.

Regards,
Dmitry.


On 15 September 2016 at 11:28, Rob Atkinson <rob@metalinkage.com.au> wrote:

> I was asked to provide an example around the use of the QB4ST model:
>
> simply this:
>
> In RDF datacube there is a thing called a qb:DataStructureDefinition -
> which "will be reusable across other data sets with the same structure." [1]
>
> I has qb:components - which may reference the dimension property:
>
> eg:dsd-le a qb:DataStructureDefinition;
>     # The dimensions
>     qb:component [ qb:dimension eg:refArea;         qb:order 1 ];
>
>
> so in your data you have property called eg:refArea.
>
> QB4ST simply defines some such dimension Properties, and some attributes
> to parameterise them:
>
> eg:dsd-le a qb:DataStructureDefinition;
>     # The dimensions
>     qb:component [ qb:dimension qb4st:Xdim; qb4st:crs ogc:4326 ];
>
>
> The idea is that QB4ST is simply a set of definitions for the most common
> spatio-temportal dimensions and measures, and defines a set of properties
> needed to parameterise them in use.
>
> (I may have made a horrible mess of the OWL - but the intent is quite
> simple)
>
> One implication is that a domain-specific approach such as the ANU-LED
> example [2] , which current locally defines such components:
>
> :positionComponent a owl:NamedIndividual , qb:ComponentSpecification ;
> qb:dimension led:location .
>
> :latitudeComponent a owl:NamedIndividual , qb:ComponentSpecification ;
> qb:dimension led:lat .
>
> :longitudeComponent a owl:NamedIndividual , qb:ComponentSpecification ;
> qb:dimension led:long .
>
> would reuse QB4ST definitions - thus creating some degree of
> interoperability with other data, which otherwise would have no way of
> interpreting led:lat as a spatial dimension. (Re-use could be direct or by
> a rdfs:subPropertyOf)
>
> (This is feedback on the RDF QB for data work - it needs to be modularised
> so that common things can be common - QB4ST is intended to start that
> process. The ontology ANU-LED [3] includes generic stuff about dimensions
> as well as domain-specific things about how images may be encoded.  I think
> this should break down into at least two components - QB4ST and a
> coverages-specific ontology (QB4Grid?), with things like
> :containsSquare a owl:ObjectProperty ;
> rdfs:subPropertyOf ogc:sfContains ;
> rdfs:domain :GridSquare ;
> rdfs:range :GridSquare .
> QB4ST is the common set of semantics for spatio-temporal dimensions and
> measures that applies to any collection (arguably these are all coverages -
> but they can be coverages of areas, and the areas may even overlap
> spatially - so I think we should just think of spatial datasets, and the
> QB4Grids  would be a coverages-specific
>
> The other plan is for QB4ST to be maintained not as a single ontology file
> but as a register, so that as each OGC or W3C specification that comes
> along that has an explicit or implicit definition of such a dimension or
> measure it can be added. But lets worry about that when we have the
> necessary ontology.
>
>
> [1] https://www.w3.org/TR/vocab-data-cube/#dsd-dsd
> [2] https://github.com/ANU-Linked-Earth-Data/ontology/
> blob/master/ANU-LED-example.owl
> [3] https://github.com/ANU-Linked-Earth-Data/ontology/
> blob/master/ANU-LED.owl
>