Re: QB4ST example

Supporting a non-binding best practice to tie to a uom model via a uri
should handle such cases.

I think some key common cases such as wgs84 and gregorian calendar is worth
doing to also show the narrowing mechanism.

On Fri, 16 Sep 2016, 3:02 AM Little, Chris <chris.little@metoffice.gov.uk>
wrote:

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