RE: QB4ST example

Rob,

Not had time to digest and think, but supportive. Out of my country for a week.

Hopefully, your ontology will support or blend easily into support for those dimensions that might have an arbitrary, counted order imposed (e.g. fish or butterfly species), or a natural non-spatial ordering (e.g. UK male shoe sizes: 5, 5 1/2, 6, 6 ½, 7,…, etc

Chris

From: Bill Roberts [mailto:bill@swirrl.com]
Sent: Thursday, September 15, 2016 4:12 PM
To: Rob Atkinson
Cc: Dmitry Brizhinev; SDW WG Public List
Subject: Re: QB4ST example

Thanks Rob and Dimitry for this. Just a quick note to say I'll catch up with this properly before the TPAC meeting and make sure it is discussed there

Cheers

Bill

On 15 Sep 2016, at 14:10, Rob Atkinson <rob@metalinkage.com.au<mailto:rob@metalinkage.com.au>> wrote:
Yes - its a draft and is incomplete and needs checking - I was first trying to get the ideas across to see it made sense - lets iterate to clean it up.

Am totally fine to kill off bad ideas too - am not happy about x,y,z - we could have a generic spatial axis - remember these are dimensions - and regular grids are a special case.  Points are a Measure.

We'll need something for named grid cells like DGGS and What3words.

The start, end etc will need to be attributes of some class of qb:ComponentSpecifications - where dimensions and measures are bound to a DSD. We need to define these, they are more general than regular grids, ergo they should be in QB4ST

qb4st:crs a rdfs:Property;
    # meta:rangeIncludes qb4st:SpatialProperty, qb4st:SpatialComponentSpecification;
    rdfs:range so:CRS;
    rdfs:label "CRS binding for a component specification or a property"@en;
    rdfs:comment "Allows declaration of a CRS for any spatial propert -- do we want to leave domain open? Leaves it to a general spatial ontology to handle if CRS is a canonical URI set , or dereferences to anything specific)"@en
    .

Hopefully with a small number of iterations this can be settled. Hopefully the strategy and scope at least can be discussed at TPAC next week.

Rob

On Thu, 15 Sep 2016 at 19:55 Dmitry Brizhinev <dmitry.brizhinev@anu.edu.au<mailto:dmitry.brizhinev@anu.edu.au>> wrote:
Two more things - there are some missing definitions and inconsistent capitalisations; I assume that's because it's only a draft.

And I found the qb4st:coordGranularity property confusing. As in, I don't understand what it means from the documentation given.

On 15 September 2016 at 19:35, Dmitry Brizhinev <dmitry.brizhinev@anu.edu.au<mailto:dmitry.brizhinev@anu.edu.au>> wrote:
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<mailto: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