Re: QB4ST example

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
> 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>
> 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
>>
>
>