W3C home > Mailing lists > Public > public-rdf-dawg@w3.org > January to March 2004

RE: Use case: AFS-2:

From: Seaborne, Andy <andy.seaborne@hp.com>
Date: Wed, 31 Mar 2004 18:02:10 +0100
Message-ID: <E864E95CB35C1C46B72FEA0626A2E808028A2680@0-mail-br1.hpl.hp.com>
To: Dirk Colaert <Dirk.Colaert@quadrat.be>, "'public-rdf-dawg@w3.org'" <public-rdf-dawg@w3.org>

Dirk,

The characteristic to me of this class of request is that the client is not
asking for a set of specifically described values but instead is asking a
looser sense of "please tell me about ..."  The client does not know what
exactly will be returned and is not being prescriptive.

So for a book, the reply might contain title, ISBN, author name.  If a
description of a book has more info than that, it would be included.  But
there isn't a sense of for any book, there is a minimum set of for
information that will be there.

> I'm a bit concerned about the word 'all'.

It isn't a good choice of wording - I didn't mean to imply arbitrary linkage
of information.  In particular, I was not thinking of things that refer to
the patient (statements with that as object), just statements where the
patient is the subject - sort of like asking for the record for the patient
where the "record" is decided by the server, not fixed by the client and is
like getting back a web document (c.f. cwm's log:semantics)

The two step approach of "what can you tell me about ...." followed by a
tell me about, from the perspective of ..." is OK.. It could be combined
into one request in some situations into "tell me about <X>, I know about
vocab1, vocab2, ....".  

Example: get the details about Bristol airport:
Bristol airport has URI http://www.megginson.com/exp/id/airports/EGGD

This request does a "fetch" (my experimental version of this style of
request) on the http://jena.hpl.hp.com:2020/airports data source.

(long URL alert)
http://jena.hpl.hp.com:2020/airports?lang=fetch&r=http://www.megginson.com/e
xp/id/airports/EGGD

which returns:

<?xml version="1.0" ?> 
<rdf:RDF xmlns:apt="http://www.megginson.com/exp/ns/airports#"
         xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#">
  <apt:Airport rdf:about="http://www.megginson.com/exp/id/airports/EGGD">
    <apt:longitude>002-43W</apt:longitude> 
    <apt:icao>EGGD</apt:icao> 
    <apt:latitude>51-23N</apt:latitude> 
    <apt:name>Bristol / Lulsgate , United Kingdom</apt:name> 
  </apt:Airport>
</rdf:RDF>

and my client didn't have to know about apt:longitude etc.  In processing
the results,  it is free to ignore information it does not understand. Here,
there is only one vocabulary - in a larger example, their might also be
other vocabularies used.

	Andy

________________________________

From: public-rdf-dawg-request@w3.org [mailto:public-rdf-dawg-request@w3.org]
On Behalf Of Dirk Colaert
Sent: 31 March 2004 14:54
To: 'public-rdf-dawg@w3.org'
Subject: Re: Use case: AFS-2: 



I got into this mail threads quite late, so, excuse me if I am repeating
things that have already been mentioned in other mails.

About the use case AFS-2

<< Finds all information available, without a priori knowledge of what to
retrieve>>

 

I'm a bit concerned about the word 'all'. Many databases and ontologies will
be very heavy. If you ask all information about something you have the risk
that the query will have very poor performance. In real life situations it
often happens that entities are very much related to each other. When I try
to imagine such a query for a hospital database and I'm asking 'any
information about patient <ID>' I will drag the whole database into the
result set (at least touching many, many tables).

 

Maybe we should consider a query: "What kind of information can you give me
about patient <ID> ?"  and then, in a second time: "Give me the medical
history of this patient".

 

Dirk

 

 

 

___________________________________

Dr. Dirk Colaert MD

Production, Information Systems Architect

Agfa

HealthCare Informatics

call +32 3 444 84 08

fax  +32 3 444 84 01

 
Received on Wednesday, 31 March 2004 12:13:08 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 16:15:18 GMT