[Product-Developers] Re: PloneSoftwareCenter / PyPI : classification coherence

Tarek Ziadé ziade.tarek at gmail.com
Wed Jan 9 15:28:02 UTC 2008



Raphael Ritz wrote:
> 
> Before commenting on your specific points just a general remark
> or question from my side:
> 
>   - are we sure we know what use cases we want to cover?
> 
>     plone.org and the Plone community itself is obviously
>     one as PSC was developed for that purpose in the first
>     place but as PSC turns out to be fairly generic (could be
>     better of course, like supporting a language field OOTB)
>     it could be used for other target groups as well.
>     I for one am setting up a site for a specific scientific
>     community that also produces and publishes code.
> 
> I guess we should be careful to keep PSC and in particular
> its web UI useful even for people that find the Trove
> classifiers intimidating or too limiting or simply not
> fitting their use case.
> 
> I'm not saying that would be hard or we would be way off
> I just want to reinforce that IMHO we should have that in mind.
> 

+10 
this is very important I agree, and that's why I am working on PyPI side
to make sure we will be able for a given egg to use custom classifiers



Raphael Ritz wrote:
> 
>> 2/ Each one one of this field become a single value that is
>>    hooked to the Trove by its first discriminant:
>> 
> 
> I understand this to mean the default value for the categories etc
> vocabularies as you define them on the main SC instance, right?
> If so, site managers would still be able to prune the list and/or
> override the label shown in the UI etc.
> 

Yes, either you make it point to the trove branch, either you provide your
own
categories


Raphael Ritz wrote:
> 
>> To prevent it, the front page could look like this:
>> 
>> Internet :: WWW/HTTP :: Site Management :: Link Checking | Multimedia |
>> Multimedia :: Sound/Audio :: Analysis
>> 
>> But this doesn't look right... So my proposal is to compute a unique
>> label
>> for each leave, by adding the previous node for the leaves that have the
>> same label, in order to have the shortest unique name.
>> 
> 
> As long as it can easily be overridden manually (like indicated above)
> I think it is OK to apply whatever magic we want to come up with a
> sensible default.
> 
> I only think we shouldn't exclude the use case where people want to use
> a completely customized way to do the thematic grouping (e.g., for my
> current use case it would be rather something like
> modeling platform | specific model implementation | data analysis tool | 
> ...) while still supporting the use of Trove classifiers where it
> makes sense (license, language, platform, etc but also a more generic
> categorization).
> 
> Maybe it would even be worthwhile to support the configuration
> of a more explicit mapping from Trove's Topic classifiers to
> PSC 'categories' - I don't know.
> 

For extra categories, either it is added in the Trove field itself
either we set an extra field to make it easy for someone
to add categories whitout having to use the
Trove structure (Topic :: etc...)


Raphael Ritz wrote:
> 
>> 5/ The user will have to manage the trove himself, and a trove editor
>> could
>> help him a little bit.
>> My proposal on this is to provide a form that contains the whole trove in
>> a
>> text area
>> 
> 
> Might be a use case for the UeberSelectionWidget (usw)
> https://svn.plone.org/svn/plone/plone.app.form/branches/plip201-usw/
> 
> So much from me at the moment,
> 

I'll look at it, thanks for the feedback

Tarek



-- 
View this message in context: http://www.nabble.com/PloneSoftwareCenter---PyPI-%3A-classification-coherence-tp14692639s20094p14714193.html
Sent from the Product Developers mailing list archive at Nabble.com.





More information about the Product-Developers mailing list