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