W3C home > Mailing lists > Public > public-egov-ig@w3.org > April 2010

RE: [dcat] Tomorrow's dcat Agenda

From: Cory Casanave <cory-c@modeldriven.com>
Date: Thu, 22 Apr 2010 10:19:35 -0400
Message-ID: <4F65F8D37DEBFC459F5A7228E5052044A03DDF@DATCENTRALSRV.datcentral.local>
To: "Richard Cyganiak" <richard@cyganiak.de>, "Erik Wilde" <dret@berkeley.edu>
Cc: <public-egov-ig@w3.org>
Richard,
There are very, if anything, that <<can't>> be represented in RDF.
There are quite a few things that are overly complex or inefficient to
represent in RDF.  For example, the other day I was helping my daughter
with a school assignment and we were looking at a spreadsheet that
represented elevations on the ocean floor: LAT/LON as row/column and the
elevation in the grid cell.  Excel can even make cool graphs of the sea
floor from this.

How would this be represented in RDF?  I think you would need a resource
for each cell with a "lat", "lon" and "elevation" triple.  This is a
much less intuitive or usable representation. Of course you could argue
it has some advantages as well (you could have other aspects of that
lat/lon recorded).  But, no doubt it would be much harder to use and
take MUCH more space.  "Reifying" an element like this can almost always
make something possible, is common practice in RDF, but can introduce
complexity.

If RDF had n-tuples it would be a bit better: elevation(lat, lon,
measure) - but still not as compact. If RDF had a matrix it could
represent this structure directly. So there are always representational
tradeoffs.  Perhaps DCAT is exploring these tradeoffs.

-Cory

-----Original Message-----
From: public-egov-ig-request@w3.org
[mailto:public-egov-ig-request@w3.org] On Behalf Of Richard Cyganiak
Sent: Thursday, April 22, 2010 8:29 AM
To: Erik Wilde
Cc: public-egov-ig@w3.org
Subject: Re: [dcat] Tomorrow's dcat Agenda

Erik,

On 21 Apr 2010, at 18:33, Erik Wilde wrote:
>>
http://www.w3.org/egov/wiki/Data_Catalog_Vocabulary#Links_and_Resources
>
> http://recovery.berkeley.edu/ might be a good addition to that list.  
> as you know, it is explicitly not using a semweb approach, but it  
> certainly addresses the question of how to expose government data in  
> a lightweight and web-friendly way.

In fact, your paper that reports on this work was already listed in  
that section (under "non-RDF approaches"). I added the link to the  
recovery.berkeley.edu site as well.

One of the things I'd like to address in today's call is to understand  
any use cases or requirements that cannot be met well by an RDF-only  
solution, so input from those who have experience with, or have a  
preference for, Atom, JSON, OPML etc will be especially important today.

Richard



>
> thanks,
>
> erik wilde   tel:+1-510-6432253 - fax:+1-510-6425814
>       dret@berkeley.edu  -  http://dret.net/netdret
>       UC Berkeley - School of Information (ISchool)
Received on Thursday, 22 April 2010 14:20:01 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Thursday, 22 April 2010 14:20:01 GMT