Hi Jason, Thomas and Armando,
Thank you all for your excellent input! I won't reply to each one
individually, but I will comment on a few key points which I have tried
to group together. If necessary we can continue on these topics in
separate threads.
[Jason]
> 2. I'm not sure if SKOMOS will provide the total solution. I'm
> currently evaluating Virtuoso Open Source for providing a SPARQL
> endpoint and querying the data. I think SKOMOS might be useful for
> providing a browseable and searchable interface for non-technical
> users while Virtuoso will allow for more advanced queries and joins
> on disparate datasets.
Right, Skosmos doesn't currently provide direct SPARQL access, though it
could be integrated (see issue #318).
[Jason]
> 3. I like the idea of SKOMOS being based on SKOS since that is what
> we are using to describe our controlled vocabularies. However, I
> think the user interface and design could be improved. In the future
> it would be nice if SKOMOS allowed for selected some nicely designed
> templates or tighter integration with a CMS.
[Thomas]
> Ability to integrate with a CMS or add editorial content to front
> page
Regarding UI design, there's of course always room for improvement. Some
tweaking can be done with a custom CSS (see config.inc). We use that in
Finto to change the colors and add some icons. Possibly
theming/templates could be built on top of that. We are quite happy with
the current Finto layout (except for the front page, which could use a
redesign), but any contributions in this area are welcome.
We have done quite a lot of usability testing on Finto and tried to
address actual problem cases we've seen users struggle with. So I think
the situation is not bad, but of course, the context of use may be
different in other organizations.
Integration with a CMS is a tricky issue. Currently Skosmos has been
designed as a stand-alone PHP web application (as opposed to e.g. a
WordPress or Drupal plugin). Bringing in content from a CMS is possible
in a very limited fashion, by using the left.inc / right.inc /
footer.inc hooks and custom code which you have to write yourself.
[Armando]
> It definitely works! As an improvement, maybe working with more
> triple stores, but that's not really a big limitation for now.
The problem is mainly the lack of good text index support in triple
stores. Otherwise any SPARQL 1.1 compliant triple store should already
work. (You may remember we tried Skosmos with an old version of
AllegroGraph, there the problem was mainly that it didn't follow SPARQL
1.1 well enough.)
Last time I looked (it was about two years ago, things may have changed)
for example the Virtuoso text index was totally unsuitable for Skosmos -
it required prefix queries of at least four characters. Also 4store's
word-based text index is similarly not very useful. Bigdata has a text
index that could be used, and in fact we had it working reasonably well
at some point in the past, but then the code bitrotted and was
eventually removed.
We're quite happy with Jena Fuseki and jena-text so there is little
reason to invest resources in supporting anything else. But of course,
contributions welcome...
[Thomas]
> Captcha on the feedback form
There is no captcha, but there are some tricks in the form code
(JavaScript and PHP) that make spamming quite difficult. In practice we
don't get almost any spam via the Finto feedback form. We used to get a
lot before these were implemented.
[Armando]
> I would add support for SKOSXL. In my experience in developing
> VocBench, and as consultant for generation and publication of RDF
> content in general, I definitely understand that, even if a team
> embraces SKOSXL for content management, still an export to plain
> SKOS is necessary for final data publication. Currently, it seems
> most of large organizations keep at least metadata attached to their
> labels, and SKOSXL is a must: a very common solution is thus to
> publish labels in both formats. This guarantees compatibility with
> SKOS core clients, while providing the richest information developed
> in SKOSXL. SKOSMOS could provide a configuration for knowing what to
> look for. If you look at this page:
>
http://aims.fao.org/aos/agrovoc/c_1221 you see labels are shown in a
> simple way (as if they were plain skos core labels), but they are
> clickable and they point to the URIs of their SKOSXL description.
> This is a very simple data publishing system [2] "a la" Pubby, with
> no browsing, no concept tree, no caching etc... which are instead
> provided by SKOSMOS. I think this is a little and simple effort to
> improve SKOSMOS while representing at the same time a great added
> value.
You are right, and we have SKOS XL support on the radar (see issue
#109). But right now it hasn't been urgent for us.
I'm also a bit anxious about the usability implications. Right now terms
are only clickable in the case of semantic relationships (broader,
narrower, related), and they lead to another concept page. But if also
labels become clickable, there is potentially more confusion and many
more pages where the user may get lost. Perhaps some kind of inline
display for SKOS XL metadata would be more appropriate than a separate page.
[Thomas]
What aspects of iso-thes in particular are you interested in? We already
have support for ConceptGroup and ThesaurusArray. Also there is at least
partial support for ConceptGroups nested using superGroup/subGroup so
for example the most recent version of the UNESCO Thesaurus groups can
be browsed:
http://skosmos.dev.finto.fi/unesco/en/groups
Some of the iso-thes constructs are built on top of SKOS XL so we would
need to support that first to be able to support them as well.
In practice we haven't been working with enough datasets making use of
iso-thes (except the above mentioned structures) to be able to have real
use cases to implement. I'm only aware of the Getty vocabularies making
use of iso-thes features that we don't already support, do you know of
others?
[Thomas]
> Ability to handle different versions of the same thesaurus over time
This is a tricky one... I'm somewhat involved in the skos-history
project (
https://github.com/jneubert/skos-history) and I know it is used
to provide access to change lists for the STW Thesaurus (see
http://zbw.eu/stw/version/about.en.html). But I'm not sure how this kind
of functionality could/should be implemented in Skosmos, which currently
only deals with the most current data. Ideas welcome!
[Armando]
> Speaking of publishing system, maybe SKOSMOS could also be turned
> into a publishing system (i.e. resolve URI dereferenciation for all
> hosted resources). Not a general triple publisher such as Pubby, not
> as reconfigurable as Loddy, but very much verticalized on thesauri,
> mixing up http dereferenciation with the already existing browsing
> possibilities. Again, maybe not too much to implement, and a great
> value added to the existing system.
It can already be used that way - Skosmos can obviously provide HTML
pages for concepts, and the Skosmos REST API can serve
content-negotiated RDF responses (RDF/XML, Turtle, JSON-LD) of concept
information. What is missing is the first point of access that needs to
perform a 303 redirect to the appropriate representation - this is
generally outside the control of Skosmos, of course depending on the URI
design (but I'd hate to see a /skosmos/ part in actual concept URIs).
For Finto and YSO, we have implemented redirection rules for the
www.yso.fi domain as rather simple Apache mod_rewrite rules that
redirect to the Skosmos installation according to the Accept header. Try
for example:
wget --header 'Accept: text/html'
http://www.yso.fi/onto/yso/p1234
wget --header 'Accept: text/turtle'
http://www.yso.fi/onto/yso/p1234
[Thomas]
> French translation
[Armando]
> Pls send me the list of all label/terms/text content in the UI of
> SKOSMOS and I will gladly send you back the Italian version!
I have previously set up a translation project on Transifex where it is
possible to translate Skosmos to several languages that FAO has
indicated it would like to support:
https://www.transifex.com/national-library-of-finland/skosmos/
French is listed but not yet started. This would be good to coordinate
with FAO.
Italian is not currently an option on the Transifex project, though it
could be easily added.
The Transifex strings are currently a bit out of date as there have been
a few new translated strings introduced in 1.2 and the upcoming 1.3
version. I will try to update it to the most recent strings soon.
Of course, translations can also be maintained and contributed the
traditional way, using po files. See here:
https://github.com/NatLibFi/Skosmos/wiki/Translation
[Thomas]
> As the developer of SKOS Play (
http://labs.sparna.fr/skos-play), I
> may also think about an integration with SKOS Play to :
>
> Use SKOS-Play as a "bask-office" for SKOSMOS to upload a vocabulary;
> Pregenerate PDFs views (+ others) of the thesauri to publish them
> in SKOSMOS;
That would be awesome!