W3C home > Mailing lists > Public > public-sdw-wg@w3.org > September 2016

QB4ST example

From: Rob Atkinson <rob@metalinkage.com.au>
Date: Thu, 15 Sep 2016 01:28:11 +0000
Message-ID: <CACfF9Lzkpq99dJ-FfaGw0-cBzSQwZO9uZDuFaCgCfOnCX6CVfA@mail.gmail.com>
To: SDW WG Public List <public-sdw-wg@w3.org>
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
Received on Thursday, 15 September 2016 01:28:55 UTC

This archive was generated by hypermail 2.4.0 : Thursday, 24 March 2022 20:31:26 UTC