- From: Erik Wilde <dret@berkeley.edu>
- Date: Thu, 22 Apr 2010 10:12:59 -0700
- 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 UTC