Re: QB4ST example

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