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

RE: Use case: tiger map/census data: have it your way

From: Seaborne, Andy <andy.seaborne@hp.com>
Date: Thu, 18 Mar 2004 15:03:53 -0000
Message-ID: <E864E95CB35C1C46B72FEA0626A2E80801EA1637@0-mail-br1.hpl.hp.com>
To: Patrick Stickler <patrick.stickler@nokia.com>, ext Dan Connolly <connolly@w3.org>
Cc: RDF Data Access Working Group <public-rdf-dawg@w3.org>

----Original Message----
From: Patrick Stickler
Sent: 18 March 2004 08:24
To: ext Dan Connolly
Cc: RDF Data Access Working Group
Subject: Re: Use case: tiger map/census data: have it your way

> This seems like a use case intertwined with an implementation
> proposal/wish.
> I think it's useful if our use cases are expressed in terms of
> the anticipated DAWG recommendation, so that it is clear which
> bits are facilitated by the recommendation and which bits are
> addressed by other specs/recs, or by client-specific functionality.

Two of Dan's qualities of the ideal use case are:

. . .

  -- engage potential users of our technology
	and convince some of them to closely
	review our spec

  -- be clear and engaging enough to
	get picked up by journalists and copied
	into trade press stories
. . .

> I think it's useful if our use cases are expressed in terms of
> the anticipated DAWG recommendation,

While I have sympathy with having use cases be framed in terms of the future
rec (i.e. diving into tehtechnical), I am also aware that, as a group, we do
not have a sense of what that recommendation is.  I like the qualities Dan
provided as they are outwardedly focused, not technology focused.  Getting
engagement with the wider audience means talking about the value provided
and less about the "how".

So I see use cases serving as input to a refinement step.  Let's not jump
too early and only make use cases a technical description.  The need for a
technical feature needs to be backed with an illustrative use otherwise it
is a requirement with unclear value.

If we find that many use cases are covered by one technical aspect, then
that's good.  We will come out of the first phase with concise requirments
that cover a range application/user needs.


> Let's presume that this knowledge already is accessible as a big RDF
> graph, and that the means of access complies to the DAWG recommendation.
> Then this use case seems to intersect
> PS-2: Resource discovery; query by example
> PS-11: Datatype Value Comparisons, Minimal Operator Set
> insofar as what we might expect the DAWG recommendation to cover;
> i.e. identify resources having particular characteristics, with
> query resolution involving datatype comparisons, and return
> descriptions of the matched resources.
> It striks me that calculating an area based on a radius of 50 miles
> and restricting locations to those within that area seems
> like a pretty specialized application -- and such a calculation
> would probably be out of scope for a general solution such
> as the expected DAWG recommendation.
> However, the client could perhaps express the equivalent
> geographic area constraints itself by greater than
> and less than constraints of the latitude and longitude
> values relative to those of Boston. E.g.
> --
> A client wishes to identify resources which have a geographical
> location within a 50 mile radius of the city of Boston.
> The client is aware of a knowledge source from which such
> resources might be discovered, based on their latitude
> and logitude.
> The client first formulates a query to the knowledge
> source explicitly asking for a description of the
> city of Boston, from which it obtains the latitude and
> longitude of boston.
> Based on the known geographical formulas, the agent
> constructs a set of templates which roughly constrain
> pairs of latitude and longitude values to those no more
> than 50 miles distant of Boston (the area may be defined
> more as a square than a circle in order to reduce the
> number of templates) and submits the query
> to the knowledge source.
> The knowledge source returns a set of zero or more
> descriptions of resources which match one or more
> of the query templates.
> --
> Now, it's clearer what functionality is provided by
> the DAWG recommendation and what functionality is
> client-specific, but facilitated/enabled/augmented
> by the DAWG recommendation.
> Yes?
> Patrick
> On Mar 17, 2004, at 20:06, ext Dan Connolly wrote:
> > 
> > 
> > The U.S. Census Bureau provides some really nify data
> >   http://www.census.gov/geo/www/tiger/tiger2003/tgr2003.html it's
> > public domain. 
> > 
> > I want to do a query like
> > 	tell me the lat, lon, name, and type
> > 	of everything within 50 miles of Cambridge, MA
> > 
> > Right now, I have to download all the files, unzip them,
> > read a bunch of docs, write some software, blah blah blah.
> > 
> > I'd like to just look at it as a big RDF graph and issue
> > a query.
> > 
> > Hmm... it's not clear they (the census folks) have motivation
> > to offer a query service. But clearly a third party could.
> > 
> > --
> > Dan Connolly, W3C http://www.w3.org/People/Connolly/
> > see you at the WWW2004 in NY 17-22 May?
Received on Thursday, 18 March 2004 10:04:44 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 15:00:42 UTC