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

Re: [dcat] Tomorrow's dcat Agenda

From: Erik Wilde <dret@berkeley.edu>
Date: Thu, 22 Apr 2010 10:12:59 -0700
Message-ID: <4BD0839B.2080303@berkeley.edu>
To: public-egov-ig@w3.org
CC: Cory Casanave <cory-c@modeldriven.com>, Richard Cyganiak <richard@cyganiak.de>
hello.

just to follow up on today's call.

Cory Casanave wrote:
> 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.

and these trade-offs are not just representational, they are caused by 
the structural limitations/features of the metamodel. whether you're 
using trees, graphs (triple-based or n-tuples) or matrices/tables makes 
a huge difference in modeling. of course you can always map one thing to 
the other through a set of rules, but for certain domains you will end 
up with models that look pretty useful and straightforward in one 
metamodel, and pretty awkward in others. having said that, i think it is 
important to be aware of this and to make an explicit choice and say "we 
do trees", "we do graphs", or "we do tables", and then just move on. 
UML, as proposed today, will also not magically solve this problem, it 
would just be a slightly different take on the "let's use graphs" side 
of things.

whatever we're doing about this, what's really important for me is that 
we're also looking at the services that are provided around those data 
structures. how can clients interact with those? at which level of 
granularity? what are update/notification capabilities? how should those 
be exposed? i still believe that the failure of the feed approach that 
was first mandated in the recovery.gov guidelines (and later removed) 
was mostly the problem that there were no guidelines or examples, so the 
feeds produced were radically different and sometimes useless, which 
meant that no useful services could be built on them (we really tried 
hard and it was impossible). this could have been avoided with more 
specific guidelines and best practices, maybe even combined with 
"validation" tools that would have allowed publishers to easily test 
whether their feeds follow the guidelines.

cheers,

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 17:14:00 GMT

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