Patrick,
VOQL should be driven by the science user scenarios. And in fact there are a few constraint-based reasoning requirements there. For example, finding fast moving objects puts constraints on positions at different times. And, obtaining ranges in a color requires constraints on differences of fluxes in 2 bands. So, one needs to allow some arithmetic on the variables of the constraints. But, we don't want to introduce things like fuzzy constraint satisfaction (where one associates an importance weighting for each constraint) until/unless one has a real science use case that requires it. If you do have specific science cases that require more than simple arithmetic in the constraint variables, let us know.
Ed
Patrick Dowler wrote:
>On February 24, 2003 12:05, Ed Shaya wrote:
>
>
>> I just want to reiterate that I think VOQL should be a means for the
>>
>>astronomer to clearly specify what astronomical knowledge he/she wants.
>> It should not require the astronomer to know how data is arranged at
>>each of the data centers, nor all of the steps required.
>>
>>
>
>This point cannot be over-emphasized. Storage data management by
>services/institutions will vary alot and it must remain a hidden implementation
>detail - with plenty of freedom on the part of a service to implement in a
>suitable fashion.
>
>
>
>>The astronomer thinks "I am interested in objects with such and such
>>properties" and VOQL should allow a description of these constraints,
>>
>>
>
>With the ention of the word "constraints", I'll jump in here:
>
>Our work at CADC and some of my past work has been in the area of
>constraint systems. The great advantage of constraint-based systems is
>that they do not, in the general case, specify a query system per se. The
>same constraint system can be applied as a query, a processing (typically
>filtering) step, a theorem-prover, etc.
>
>Since VOQL is still young, I suggest that instead of inventing a "query language"
>we will be better servced by a constraint toolkit. The advantages are many:
>
>- easy to convert to a query
>- easy to apply as a processing or filtering step
>- easy to build a UI that allows users to construct constraint systems since
> constraints are "things" to be created and manipulated
>- easy (well, easier :-) validate
>
>Although I don't go crazy for this sort of thing:
>
>- easy to serialize as XML (constraints are things with simple parent-child relations
> between them and the expressions, operators, and constants in use)
>
>My 2c (although I guess Canadians should up that to 3c),
>
>
>
>
Received on 2003-02-25Z00:29:07