Re: QB4ST - Spatio-temporal extension to RDF-QB

I think we need to be a bit careful we dont mix concerns - my proposal is
for a set of abstract spatial dimensions (and means to define how a
specific data set will parameterise these). From what I understand of the
ANU work its more focussed on encoding observations. Thus there needs to be
two products - it doesnt make sense to put them into a single ontology.
The ANU_LED should refrain from redefine any basic concepts that would be
of more general utility, since if everyone did that we'd end up with no
means to identify what is common or different about data sets. I.e. it
should re-use common concepts.

There is also an inconsistency in the ANU_LED - coordinates are not
dimensions - they are measures (a dimension has a value which is part of an
index identifying a specific record - qb4st defines both options - and IMHO
its this sort of complexity in the interpretation which makes it critical
to have a single canonical library of such basic definitions - much easier
to understand a documented solution than to try to get it right for each
application, and expect everyone do it the same way,

Thus, for an example, in ANU_LED replace

:latitudeComponent a owl:NamedIndividual , qb:ComponentSpecification ;
qb:dimension led:lat .
with
:latitudeComponent a owl:NamedIndividual , qb:ComponentSpecification ;
      qb:measure geo:lat;

Note that Qb4ST defines additional axioms about the characteristics of the
externally defined geo:lat  - so if you import qb4st its possible to find
out that its a type of spatial measure for example.

What I'm not sure about is whether I have the OWL correct - but I am sure
that the sort of things I've defined in my straw-man are necessary.  I'll
tweak it to include a dimension bound specifically to lat/long in WGS84 -
to match the dimension option above (for example if data is a grid coverage
based on lat/long increments.

Rob




On Wed, 17 Aug 2016 at 22:20 Bill Roberts <bill@swirrl.com> wrote:

> Thanks Dmitry.  Agree that we should aim for consensus and an integrated
> single outcome on use of data cube for coverage data.
>
>
>
> On 17 August 2016 at 13:04, Dmitry Brizhinev <dmitry.brizhinev@anu.edu.au>
> wrote:
>
>> The ANU team thinks it would be good to look at Rob's work and ours
>> side-by-side and synthesise the important bits into a final product.
>> We submit for your consideration the ontology we've been using:
>>
>> https://github.com/ANU-Linked-Earth-Data/ontology/blob/master/ANU-LED.owl
>>
>> And a minimal example of how it can be used:
>>
>>
>> https://github.com/ANU-Linked-Earth-Data/ontology/blob/master/ANU-LED-example.owl
>>
>>
>> It would be really instructive if Rob could construct such an example for
>> QB4ST. I (for one) find it much easier to understand ontologies that way :)
>>
>>
>> Regards,
>> Dmitry Brizhinev
>>
>>
>>
>> On 16 August 2016 at 17:46, Bill Roberts <bill@swirrl.com> wrote:
>>
>>> Thanks Rob - will read and comment
>>>
>>> Cheers
>>>
>>> Bill
>>>
>>> On 15 August 2016 at 08:51, Rob Atkinson <rob@metalinkage.com.au> wrote:
>>>
>>>> I have created an initial set of specialisations of RDF-QB elements to
>>>> support an interoperable means of describing spatio-temporal
>>>> characteristics of dimensions and measures in metadata about data sets.
>>>>
>>>> There is a wiki page with some introduction to RDF-QB here:
>>>> https://www.w3.org/2015/spatial/wiki/RDF_Datacube_for_Coverages
>>>>
>>>> and the ttl is here:
>>>>
>>>> https://github.com/rob-metalinkage/sdw/blob/gh-pages/coverages/qb4st/qb4st.ttl
>>>>
>>>> (and i generated a pull request).
>>>>
>>>> Requesting a sanity check ASAP - and feel free to educate me on how
>>>> such things _ought_ to be defined - first step is to outline what is
>>>> required and what it needs to do - then we can refine the logic and
>>>> language.
>>>>
>>>> Cheers
>>>> Rob Atkinson
>>>>
>>>
>>>
>>
>