Organization abbreviation/acronym

[davidread]

I'd like to draw together a common way to store an organization's abbreviation or acronym in CKAN.

Does anyone else suffer from long official names? In the UK we have ones like "Department for Environment, Food & Rural Affairs" which is commonly abbreviated to "DEFRA", and on data.gov.uk we choose to record them both. We allow users to search publishers using the abbreviation, and I've received a pull request on ckanext-hierarchy to display in the breadcrumbs the abbreviated names of the organization and parent organization.

It would be good to agree on the name of the extra field and whether it is for the abbreviation or long name (and the abbreviation is stored in the main organization.title), or something else. If we establish a common way, then it allows for someone to add this into core CKAN.

So, do say what fields you use for this and any other comments.

[davidread]

On data.gov.uk:

organization.title - official name e.g. Consumer Council for Water organization.extras['abbreviation'] - abbreviation/acronym e.g. CCWater

[torfsen]

Is setting organization.title to the short form and storing the full name in the extras an option? Or using the abbreviation for name and the full name for title?

I think we already have a fairly complicated system of names for things (most have an id, a name, and a title) so I'm not sure whether adding yet another component to that makes things easier to use.

[davidread]

Yes, that's the option suggested in the PR I mentioned. I'd be interested who uses it and the reasons why. I'd have thought that the average user doesn't know what all the abbreviations are when seeing them shown

It sounds like you don't think it is compelling enough to justify the changes to the core model - you don't think there is big enough need for allowing the users to be able to search by both full name and abbreviation. Is it because abbreviations are not a big deal for your site?

Also, which user are you referring to when you're concerned about the complicated system? The end-user seeing the 2 variants of the name? The publisher being invited to enter both? The developer using the API dealing with id, name, title and abbreviation? Or is it general concern about adding more code?

[torfsen]

We currently don't use abbreviations on our site, but I can see how other sites need a way to integrate them.

I think storing both the abbreviation and the full name is a good idea, because you want to at least allow users to search for something using both. I can also understand the wish for using the abbreviation in the UI if the full name is very long.

I'm just hesitant to introduce some special-purpose property to a core model unless there are very good reasons to do so -- that doesn't mean that your reasons aren't good enough, just that I'm not sure whether I understand them completely.

From an end user's perspective, the important points seem to be

• Content can be found using all its common names, including the full name and a potential abbreviation.
• Names in the UI should be easy to understand. If a name is too long for a certain type of label then one solution is to truncate it. However, that may lead to several different names that yield the same truncated name, e.g. when you have Ministry of X and Ministry of Y that both get truncated to Ministry .... Hence, a distinct short name (like an abbreviation) could be a good alternative. In any case the full name should be available via tool-tip.

From the point of view of a developer (either working on CKAN, an extension, or with the API), the important point is that there's a clear idea of how names are assigned to entities and which name is chosen when. In addition something as central as a naming scheme shouldn't be specific to organizations, but should be the same for all entities (packages, resources, ...).

Currently we have id, name and title. id and name can often be used exchangeably -- name has the benefit of being human-readable (good, e.g., for URLs) while id won't change (even if name does). title is an optional, complete, human-readable name which (AFAIK) defaults to name and which is the standard label for the UI.

In my opinion, that is already quite complex, and I'm not sure whether adding another property, say, short_title, would improve things. At the very least, one would have to define the semantics of title in the case it isn't set (but name and short_title are). In addition, one would have to have some kind of default short title in case short_title isn't set, e.g. something like

def get_short_title(self):
    return self.short_title or truncate(self.get_title(), 20)

On the other hand, name cannot be simply used for display purposes, since (AFAIK) it should be URL-friendly, so some short names may not be valid for name.

Unfortunately I don't have a clean solution :wink:

[espona]

I tried to implement this in my version of the hierarchy-extension (https://github.com/espona/ckanext-hierarchy) in the simplest way for me, given my little knowledge of CKAN.

I needed a short name of the organization to display the names in tree sections on the side pane, in the navigation breadcrumbs that now show the hierarchy (ex. Organizations/org1/org2/org3), etc. The option of truncating them doesn't look very good to me since mostly shown not relevant parts of the name ("National Institute of...") as you already pointed out.

I first added a field called "shortname" for this purpose but then I realized it is used more often than the long full name. In my experience the long name is only used in the organization "about" page and in the organizations "index" page, for all the rest, the shorname is more useful (breadcrumbs, facets, tags, etc.). So I added the non-mandatory long name field and leaved the title field for the short name. This solution required minimal changes and leaves anyway the possiblity for the user to define the full name in the title which will be truncated as usual if needed.

I didn't like the idea of using "name" as shortname since I wanted to have freedom regarding the characters and the upper/lowercase are important (ex. ForeMa).

I do not know enough to evaluate at a more general level this solution, but I thought it may be good to share my use case. I put below a screenshot of my CKAN instance.