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)