[ckan-discuss] Next version of the LOD cloud diagram. Please provide input, so that your dataset is included.
john.bywater at appropriatesoftware.net
Wed Sep 8 22:33:38 BST 2010
William Waites wrote:
> On 10-09-08 17:47, Ted Thibodeau Jr wrote:
>> When I ignore that and do dive into editing DBpedia's listing,
>> I discover --
> (Leaving your comments intact for the ckan-discuss list, you
> are correct that it is an RDBMS system and that starts
> showing through clearly when people used to thinking in an
> RDF or EAV way start throwing data at it. I am particularly
> interested in looking at ways to improve this, keeping in
> mind that it is a running system with real users and a lot
> of effort that has gone into building it -- so we need to be
May I admit to being curious about this analysis? :-)
I see an email form field, a complaint about wanting to put a non-email
value into an email form field, and then a discussion about persistence
I don't see how a consideration of a form field can trigger a discussion
about the particular cohesive mechanism for persistence which happens to
be used by CKAN (the widely praised SQLAlchemy).
Looking at the Ted's text, I can see that Ted appears to be trying to
input a non-email value into an email field. I can also see that email
form fields are widely available in all the web application frameworks.
I can see that they are frequently used, and that all of them accept
only email addresses.
At first sight, it looks like a rather energetic leap, to jump from an
email form field, straight over the domain model, and on to a critique
of the cohesive mechanism for persistence.
Perhaps mistakenly, I would hazard a guess that it's just a form field
Could I ask, which form field (or fields) would be preferred instead of
the existing email form field?
Would a free text field be preferable? Or is there an RDF form which
allows exactly the balance of degrees of constraints and degrees of
freedom which would satisfy each and every user, regardless of what kind
of thing they are trying to record?
Additionally, I suspect that if there is a constraint on the number of
extras or the number of resources that any one package can have, that it
has absolutely nothing to do with the cohesive mechanism for persistence
used by CKAN.
What have I overlooked? :-)
More information about the ckan-discuss