[wdmmg-dev] types, names and URLs

Mon Sep 19 17:17:06 UTC 2011

On Mon, Sep 19, 2011 at 2:33 PM, Friedrich Lindenberg <
friedrich.lindenberg at okfn.org> wrote:

>
> On Mon, Sep 19, 2011 at 3:20 PM, Martin Keegan <martin.keegan at okfn.org>
> wrote:
> > I propose that we abandon the value/classifier/entity distinction, and
> have
> > the following properties for dimensions
> >
> > 1) a boolean "final endpoint" flag
>
>
> This is a bit fuzzy. How:
> * do we flag spenders?
> * if there are multiple entities involved in receiving the funds, does
> one, many or any of them get the flag?
>
> I just mean that each dimension have a flag which means "this dimension
would have been an entity, rather than a classifier under the previous
system".

This is a useful concept, and basically corresponds to the nodes of the
global graph of spending datasets.

(Currently we assert that we have a "from" entity and a "to" entity, though
in practice these are often hacks like "Society" or "Government"; we
probably want to relax this to "no more than one spender dimension and no
more than one recipient dimension"

> > 2) a taxonomy, which may be null
>
> I wouldn't allow null, will only give us trouble while building URIs.
> Why not have entities get a default taxonomy "entity". Only makes
> sense in combination with:
>
> All I was meaning to say was that taxonomy should be optional. I appreciate
there is some confusion between optional and null (for an hilarious example
of someone who just Does Not Get It, see
http://beust.com/weblog/2010/07/28/why-scalas-option-and-haskells-maybe-types-wont-save-you-from-null/),
and I'm guilty of it myself above.

At the moment, taxonomies are obligatory for classifiers and prohibited for
entities and values.

Where a dataset contains something a dimensions which has to be a classifier
under our present scheme, the wrangler has to fake up a taxonomy name to get
the mapping to validate; this should be unnecessary. Furthermore, entities
may well want taxonomies.

We should change to allowing taxonomies on any dimension, and making them
non-mandatory.

> > 4) that all dimensions's mappings be in the classifier/entity multicolumn
> > format
>
> While I'm not eager to keep the simple format, I do like having
> non-nested, simple data attached to entries. It seems theoretically
> ugly but in practice its quite nice. Assume, e.g. a transaction number
> for each entry: why not keep it inline instead of building its own
> table?
>
> I was only referring to the JSON mapping format; "value" dimensions don't
have the same schema as "classifier" and "entity" dimensions, and this is an
absolute pain in the arse when trying to write them programmatically

> > Classifiers and entities currently each have a namespace, which is
> > represented in URLs, and is non-dataset specific. I'm not sure what I
> want
> > to see happen to that, and would appreciate suggestions.
>
> The URL scheme I would propose is:
>
> [snip scheme]

I'm trying to ask two questions:

If we "bunker" datasets, it becomes a bit harder to maintain the current URL
schema which involves global namespaces for entities and classifiers. I'm
not sure anyone is using this much at the moment. Are we Ok with abandoning
the current global namespaces? (That's not to say we shall not provide
something similar once the "Facebook of spending" idea comes to fruition)

We currently have separate namespaces for entities and classifiers: if we
remove the distinction between these concepts at the mapping/analytic level,
should they likewise be merged at the URL namespace level?

Mk
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.okfn.org/pipermail/openspending-dev/attachments/20110919/6b517975/attachment.html>