[ckan-discuss] Next version of the LOD cloud diagram. Please provide input, so that your dataset is included.

[John Bywater]

Hi Will,

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
> gentle).
> 

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 
mechanisms.

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 
issue.

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? :-)

J.