Re: Use Case: DC-01

On Apr 02, 2004, at 15:21, ext Dirk Colaert wrote:

>
>
>> This sounds like "best match", which would require some forumula
>> for ranking alternative results, which may be alot of work.
>>
>> I personally like this use case, and think it definitely reflects
>> real-world needs. I'm just wondering if it's (a) too big to take
>> on and (b) something that needs more research/exploration before
>> standardizing.
>
> I certainly agree that solving the query is a difficult task. But I 
> guess
> this is outside the scope of the workgroup. The point is do we need a 
> query
> language capable of:
> 1- giving constraints (no doubt I guess)

What sort of constraints? Time? Size of results? Others?

> 2- imposing a sort order on some criteria
> The difficulty is that that 'criteria' is not necessarily a data 
> element in
> the rdf document but implied in the rules within the document (as you 
> said:
> "best match").

I think sort order, even ranking, could be approached by defining a
proxy which post-processes the generic DAWG results in terms of a
particular, solution-specific "best match" metric.

So...

Client -> [query] -> DAWG Server -> [results] -> Proxy -> [ranked 
results] -> Client


>
> The relevance of the Use Case is that it points clearly to that 
> capability.
> It is up to the WG to decide whether or not we want the QL to have that
> functionality.
>
> My point is: The problem is very common so, if we can't express this 
> problem
> with SQL, if we can't express the problem with xpath/opath (object 
> oriented)
> then we should do it with the query language were are designing now.
> Otherwise we have to wait until yet another more high level language 
> shows
> up.
>
> If we accept RDF as a means to store knowledge and meaning then an RDF 
> query
> language should be able to handle something like 'relevance' and 'best 
> fit'
>
> Right?

I'm inclined to agree, but think that this is something that probably
should be left to a later interation of this or some other WG.

Though, it certainly should be something we keep in mind during this
first iteration, so that whatever we come up with this time around will
be condusive to addressing results ranking at a later stage.

But that's just my take on this...

Patrick


>
> Dirk
>
> ___________________________________
> Dr. Dirk Colaert MD
> Production, Information Systems Architect
> Agfa
> HealthCare Informatics
> call +32 3 444 84 08
> fax  +32 3 444 84 01
>
>

--

Patrick Stickler
Nokia, Finland
patrick.stickler@nokia.com

Received on Monday, 5 April 2004 05:24:25 UTC