Navigation path

Asset Description Metadata Schema for Software

(
 
)
3.37/5 | 19 votes
Editor's choice

ADMS.SW plugin for FusionForge

10 message(s)
Olivier Berger
ADMS.SW plugin for FusionForge
Posted by Olivier Berger on August 21, 2012 at 18:50.
( Institut Mines-Telecom , France ) - 11/01/2012
.
(
 
)
3/5 | 2 votes
"

I've contributed a first version of an admssw plugin for FusionForge.

More details at : https://fusionforge.org/plugins/mediawiki/wiki/fusionforge/index.php/ADM...

Comments

Stijn Goedertier
Re: ADMS.SW plugin for FusionForge
Posted by Stijn Goedertier on August 21, 2012 at 22:51
(PwC, Belgium) - 10/05/2016
"

Congratulations, Olivier. This is terrific news. I had a look at your code (admsswPlugin.class.php) and it looks great. I have some questions though:

  • Please let us know whether and how we can best help you (e.g. testing, documentation, promotion, ...).
  • Is there a running instance / VM image on which I could try out the content negotation?
  • Do you expect the plugin to be backward compatible with older releases of FusionForge?
  • Do you think it is feasible to add properties for the "trove" categories at project-level?
  • And what about adding releases (admssw:Release) and individual download files (admssw:SoftwarePackage) at project-level?

 

 

Olivier Berger
Re: ADMS.SW plugin for FusionForge
Posted by Olivier Berger on August 31, 2012 at 11:14
(Institut Mines-Telecom, France) - 11/01/2012
"

I guess any help is welcome, thanks.

To test it, the best is probably to test the installation I've made on https://fusionforge.int-evry.fr/

For instance, you may :

 $ curl -v -k -H 'Accept: application/rdf+xml' https://fusionforge.int-evry.fr/projects/admsplugff/

Or even :

$ curl -s -k -H 'Accept: application/rdf+xml' https://fusionforge.int-evry.fr/projects/admsplugff | rapper -o turtle -I https://fusionforge.int-evry.fr/projects/admsplugff/ - 2>/dev/null
@base <https://fusionforge.int-evry.fr/projects/admsplugff/> .
@prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> .
@prefix doap: <http://usefulinc.com/ns/doap#> .
@prefix dcterms: <http://purl.org/dc/terms/> .
@prefix oslc: <http://open-services.net/ns/core#> .
@prefix rad: <http://www.w3.org/ns/radion#> .
@prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> .
@prefix schema: <http://schema.org/> .

<>
    oslc:serviceProvider <../../plugins/oslc/cm/oslc-cm-services/13> ;
    dcterms:description "The goal of this project is to develop a FusionForge plugin to provide ADMS.F/OSS metadata in /project pages with content negociation" ;
    dcterms:isPartOf <../../projects> ;
    dcterms:subject "ADMSFOSS", "DOAP", "LinkedData", "RDF", "SemanticWeb", "forge", "fusionforge", "interoperability", "metadata", "projects" ;
    schema:contributor <../../users/obergix#person> ;
    doap:description "The goal of this project is to develop a FusionForge plugin to provide ADMS.F/OSS metadata in /project pages with content negociation" ;
    doap:homepage "https://fusionforge.int-evry.fr/www/admsplugff/" ;
    doap:name "admsplugff" ;
    doap:shortdesc "ADM.F/OSS plugin for FusionForge" ;
    a <http://purl.org/adms/sw/SoftwareProject>, doap:Project ;
    rdfs:comment "Generated with the doaprdf and admssw plugins of fusionforge" ;
    rad:keyword "ADMSFOSS", "DOAP", "LinkedData", "RDF", "SemanticWeb", "forge", "fusionforge", "interoperability", "metadata", "projects" .

It surely can be improved, and the code is in the FusionForge SVN.

The plugin somehow depends on the 5.2 codebase, but should be backported without too much effort... on the other hand, FusionForge 5.2 will bring other benefits, so not sure saving an upgrade is the best strategy ;)

About the releases, troves, etc., yes, there's indeed a lot to add to it, to make it really useful, but I'll let that for the future and/or other contributions. I'm busy implementing ADMS.SW support in Debian at the moment ;)

Olivier Berger
Re: ADMS.SW plugin for FusionForge
Posted by Olivier Berger on February 01, 2013 at 18:43
(Institut Mines-Telecom, France) - 11/01/2012
"

Here's an update on our efforts. The plugin has been improved, although it is not ready for production, nor yet released.

But you may try and get a glimpse of what's currently supported by trying either to get HTML previews from : https://fusionforge.int-evry.fr/plugins/admssw/ or directly as Turtle (or RDF/XML if you prefer it) using :

curl -k -s -H "Accept: text/turtle" https://fusionforge.int-evry.fr/plugins/admssw/full.php

Stay tuned for more details... or feel free to ask ;-)

Stijn Goedertier
Re: ADMS.SW plugin for FusionForge
Posted by Stijn Goedertier on February 04, 2013 at 0:45
(PwC, Belgium) - 10/05/2016
"

Great work, Olivier. We have made an online version of the AMDS.SW Validator available at this URL:

http://admssw.testproject.eu:3030/admssw_validator.html

You will notice that we have relaxed some of the validation rules somewhat (raising warnings rather than errors) as you requested in a previous post. In any case, the generated HTML and the validation results look very promising so far. Michiel and I will take a closer look in the coming week.

I also really like the fact that you have made all URIs dereferenceable, as described in 'Cool URIs for the Semantic Web' and '10 rules for persistent URIs'. I understand that you have chosen the solution "Hash URIs with content negotation". Will this also be a feature of the plugin, or does it require specific configuration on the FusionForge instance?

curl -k -H "Accept: text/turtle" https://fusionforge.int-evry.fr/projects#repo
curl -k -H "Accept: text/turtle" https://fusionforge.int-evry.fr/projects/cosmos/#project
curl -k -H "Accept: application/rdf+xml" https://fusionforge.int-evry.fr/projects/cosmos/#

 

 

Olivier Berger
Re: ADMS.SW plugin for FusionForge
Posted by Olivier Berger on February 05, 2013 at 12:26
(Institut Mines-Telecom, France) - 11/01/2012
"

Thanks for your comments, Stijn.

About the content-negociation, it is supposed to be included in the plugin "out of the box" : for some of the PHP scripts already available on the forge, such as /projects or /frs/download.php, a new hook was added to the FusionForge code, that allow plugins to register as handling alternative content-types, such as Turtle of RDF/XML. The admssw plugin then makes use of these to do its job.

So in principle, any other plugin may as well exploit this for other content-types (graphical vizualisations, maybe ?).

Unfortunately, there are not always existing FusionForge "paths" looking like REST, which could be reused for such conneg RDF publication... and we try to minimize the impact on the core of FusionForge for the moment. If the plugin proves successful, we may envision more radical changes for the future.

There's also additional headers in the HTML pages which point to the alternate RDF pages whenever that sounded interesting.

Michiel De Keyzer
Re: ADMS.SW plugin for FusionForge
Posted by Michiel De Keyzer on February 15, 2013 at 19:08
(PwC Belgium, Belgium) - 23/02/2012
"

Hi Olivier,

The exported metadata look s really good! Congratulations. We have done a more detailed analysis and we think the suggestions listed below could further improve the plugin. Please look at this as suggestions and we would be happy to have your feedback on it:

Full export (https://fusionforge.int-evry.fr/plugins/admssw/full.php )

  • Is it possible to export user information as a dcterms:Agent ?
  • We don’t know if there any relevant metrics available in a out-of-the-box FusionForge deployment, for instance number of downloads? If this is the case, would it be possible to export this as a qb:DataSet. If this is the case it could then be linked to the admssw:SoftwareProject with the property admssw:metrics
  • To get it through the ADMS.SW validator, a language tag should be added to all literals. Would it possible to add this in the export?
    • doap:description
    • rad:keyword
    • doap:name
    • rdfs:label
  • We were wondering if it is possible to export dcterms:modified for, for instance a release?
  • Is it possible to have some sort of automated fill in of the property adms:metadataDate, perhaps on the moment a user exports/requests the metadata?
  • Could the property admssw:SoftwareRelease -> dcterms:language be extracted from the Trove classification “Natural Language” if the project is classified? If this is possible, it is maybe also possible to set the same value for the property adms:metadataLanguage
  • We were wondering whether it would be possible to export the properties xhv:current, xhv:next, xhv:previous if a comparison was made based on creation dates between the different releases? Perhaps it is possible to extract the information for xhv:current from the link “Download the latest release as zip: xyz.zip”.
  • We noticed that the exported information for admssw:SoftwareRelease -> dcterms:publisher refers to the project. Following the ADMS.SW specification, the dcterms:publisher refers to a dcterms:Agent .
  • Is it possible to export admssw:status for a admssw:SoftwareRelease
  • Could the Software Package -> dcterms:created property perhaps be extracted from the date information that is available next to each file?
  • We would suggest to add “bytes” as a unit for Software Package -> schema:fileSize. Would you agree with that?

Export description metadata of a particular software project

We exported the metadata for the project “admsplugff”. We noticed that only the properties of an admssw:SoftwareProject were extracted. Would it be a lot of work to also let the plugin extract the information of the associated Software Releases (admssw:SoftwareRelease) and Software Packages (admssw:SoftwarePackgages) are extracted? Offcourse the most important is that this information is already exported in the full export.

Export of the Trove taxonomies as SKOS

This looks really great. We have tested this by running it through the PoolParty validation service. No errors were returned. There were only 3 warnings:

Olivier Berger
Re: ADMS.SW plugin for FusionForge
Posted by Olivier Berger on February 19, 2013 at 16:26
(Institut Mines-Telecom, France) - 11/01/2012
"

Here's a first quick response without further investigation :

  • Is it possible to export user information as a dcterms:Agent ?
    • Do you have an example (Turtle fragment) of the kind of resource/links you would expect ? At the moment, we point to a foaf:Person Resource, in the FOAF profile of the Forge user, provided that the foafprofile plugin is installed (which may be buggy, btw, so your review may help).
  • We don’t know if there any relevant metrics available in a out-of-the-box FusionForge deployment, for instance number of downloads? If this is the case, would it be possible to export this as a qb:DataSet. If this is the case it could then be linked to the admssw:SoftwareProject with the property admssw:metrics
    • Yes, there is a download counter in the FusionForge FRS, so it could be added, but I'm not sure it will be possible to add that in the near future (focusing more on fixing existing bugs, and deployment, in the short term), unless you think this is really important for the first deployments
  • To get it through the ADMS.SW validator, a language tag should be added to all literals. Would it possible to add this in the export?

    doap:description rad:keyword doap:name rdfs:label

    • Well, the thing is that we don't know in advance which language is really used by the project admins for all the strings that have been set, in the FusionForge database… so in general, it is not possible to know, and setting a @en for all would probably be false for a forge like Cenatic's, as I'd expect quite a few spanish phrases… so maybe there isn't anything we can do, for the moment. Maybe this would lead to filing a feature request so that FusionForge handles explicit languages and/or multiple languages for project descriptions or trove categories (beyond the needs of the ADMS.SW, for the full forge).
  • We were wondering if it is possible to export dcterms:modified for, for instance a release?
    • Again, FusionForge doesn't seem to update dates on the releases in the FRS, so I'm not sure how we could handle this. For the moment, the "date" of the release available in the DB is translated to dcterms:created. Maybe the latest date of the most recent file added to the release could be translated to dcterms:modified ? I'm not sure we can make that change real soon. Is it problematic for the harvesters ?
  • Is it possible to have some sort of automated fill in of the property adms:metadataDate, perhaps on the moment a user exports/requests the metadata?
    • That should certainly be possible. I haven't really investigated the needs for the harvesters so far, so the SoftwareRepository/RADion meta-data needed for directory harvesting / consuming can be improved. I'll have a look at the details.
  • Could the property admssw:SoftwareRelease -> dcterms:language be extracted from the Trove classification “Natural Language” if the project is classified? If this is possible, it is maybe also possible to set the same value for the property adms:metadataLanguage
    • It should probably be an option, even though I'm not sure how reliable these meta-data are in general on the "average fusionforge installation"… maybe this should be checked in a sample forge (Cenatic / Adullact) ? Maybe there could be a configuration option for such details that could be activated only for particular forges that tend to enforce some project documenting policy ?
  • We were wondering whether it would be possible to export the properties xhv:current, xhv:next, xhv:previous if a comparison was made based on creation dates between the different releases? Perhaps it is possible to extract the information for xhv:current from the link “Download the latest release as zip: xyz.zip”.
    • This looks like an option. Another would be to have proper support for release trees in FusionForge, of course, which would make it explicit, and allow supporting branches for instance. It may not be common, but I'm not sure how we could represent releases made in the following chronological order :
      • 5.2
      • 5.3
      • 5.2.1

      This probably needs a bit more thinking.

  • We noticed that the exported information for admssw:SoftwareRelease -> dcterms:publisher refers to the project. Following the ADMS.SW specification, the dcterms:publisher refers to a dcterms:Agent .
    • Hmmm… yes… still, I'm reluctant to point at the FOAF profile of the very person that filed the new release in the DB, even though I think we have this information. My idea is that we would need some kind of new field in FusionForge to store proper attribution of the project owners (institutes, companies, etc.). That's something I had been thinking about in the past, when collaboration projects hosted on a particular forge aren't necessarily owned only by the hosting institutions. At the moment, only parts of the project description can help disambiguate… so in a non-semantic way :-/
  • Is it possible to export admssw:status for a admssw:SoftwareRelease
    • I don't think that we have such a field at the moment in FusionForge. So we could use a fake a resource like http://fusionforge.example.com/releasestatus/released but that doesn't make much sense for the moment as all would have it. Again, there's a potential array for improvement of the FusionForge FRS ?
  • Could the Software Package -> dcterms:created property perhaps be extracted from the date information that is available next to each file?
    • I think it is the case, AFAICT… the examples on fusionforge.int-evry.fr didn't make it clear though.
  • We would suggest to add “bytes” as a unit for Software Package -> schema:fileSize. Would you agree with that?
    • We could, but the shema.org states "In the absence of a unit (MB, KB etc.), KB will be assumed."… so I'm not sure. I'm not sure there are gonna be lots of calculations made on that field in the consumers… so we'd probably add it indeed.

Export description metadata of a particular software project

  • We exported the metadata for the project “admsplugff”. We noticed that only the properties of an admssw:SoftwareProject were extracted. Would it be a lot of work to also let the plugin extract the information of the associated Software Releases (admssw:SoftwareRelease) and Software Packages (admssw:SoftwarePackgages) are extracted? Offcourse the most important is that this information is already exported in the full export.
    • I have to check, but yes, I thnk that this should be doable without too much trouble.

Export of the Trove taxonomies as SKOS

  • This looks really great. We have tested this by running it through the PoolParty validation service. No errors were returned. There were only 3 warnings:
    • Missing language tags for skos:prefLabel (305 occurences).
      • Yes, we don't have that information in the DB, but I'm quite shure we should find a way, in particular for "translated troves" (in spanish for instance, IIRC from the discussions in the working group)
  • The skos:ConceptScheme with URI https://fusionforge.int-evry.fr/softwaremap/trove/audience has no rdfs:label.
    • Hmmm… I'm not sure anymore, but I seem to recall that skos:prefLabel was preferred… I'll have to check the SKOS docs…
  • 95 concepts do not have a top concept.
    • Hmmm… again, I'm not too familiar with SKOS to remember, but that may be easily fixed, as I think we do have pointers to the top ConceptSchemes in the DB… again, needs further investigation…
Olivier Berger
Re: ADMS.SW plugin for FusionForge
Posted by Olivier Berger on February 21, 2013 at 14:56
(Institut Mines-Telecom, France) - 11/01/2012
"

Export description metadata of a particular software project

  • We exported the metadata for the project “admsplugff”. We noticed that only the properties of an admssw:SoftwareProject were extracted. Would it be a lot of work to also let the plugin extract the information of the associated Software Releases (admssw:SoftwareRelease) and Software Packages (admssw:SoftwarePackgages) are extracted? Offcourse the most important is that this information is already exported in the full export.
    • I have to check, but yes, I thnk that this should be doable without too much trouble.

I have now fixed this one issue (I hope) in the latest commits. I have it in test on fusionforge.int-evry.fr : feedback much welcome.

Michiel De Keyzer
Re: ADMS.SW plugin for FusionForge
Posted by Michiel De Keyzer on June 04, 2013 at 15:27
(PwC Belgium, Belgium) - 23/02/2012
"

Julien Gaujal sent the following user requests on 2013-05-22 (translated)

1) Remarks relating to representation

Currently only a a "preview" of a more human-readable format project's ADMS.SW RDF description can be viewed using the plugin. Ideally the plugin is able to generate a page containing RDFa+HTML providing a full human-readable description with ADMS.SW of a particular project (simmilar to the visualisation functionality . This page should also include a short explanation of the property (e.g. dcterms:created ==> the date the project was created).

NOTE: Some of the links behind the properties in the current version of the validator (visualisation functionality), currently return an error. This mainly occurs for the properties with perfix "admssw:".

 

2) Remarks relating to functionality

Sometimes information is not exported by the plugin that is available on the homepage of a particular project (e.g. for the project TotEM there are no packages on the forge, however they are available on the website of the project). This information could be added using a spreadsheet and Google Refine but it is not possible to do add this information using the plugin. Should this information be added or should we only focus on the information available on the forge. 

Additionaly, since the ADMS.SW RDF descriptions are generated automatically, is this description automatically updated when changes are applied to a particular project? How and when does this happen?

Olivier Berger
Re: ADMS.SW plugin for FusionForge
Posted by Olivier Berger on June 06, 2013 at 16:24
(Institut Mines-Telecom, France) - 11/01/2012
"

Thanks for the feedback.

 

Here's a followup regarding Julien's remarks.

* about the 1) and user-friendliness of the meta-data preview, everything can be imagined, but the ADMS.SW meta-data is mainly geared at applications/programs/machines, so the HTML preview is just some "debugging" option. In any case, the traditional project's pages in fusionforge are there for humans.

It may be envisioned to mix boths as RDFa, but a previous attempt in the classical pages for fusionforge proved difficult, as FusionForge misses a templating system, and such a rewrite tends to have annoying side effects, like breaking validity of HTML.

There may be another option in using some stylesheet + RDF/XML combination that would allow some previewing maybe...

Thus I'm not sure it's worth improving the ADMS.SW preview pages, and there are probably many other features that could benefit from the related manpower (like support for paging in large result sets ;).

About the ADMS.SW ontology fetching errors... I guess I'm not qualified to provide any response.

 

* on the 2), unless we made a mistake at implementation time, the RDF export made by the plugin is constructed from the DB, so it should be identical to what's seen in the UI, "updated" automatically... but yes, it may be interesting to be able to provide additional meta-data. At least supporting some custom seeAlso pointer could help direct consuming apps to complementary RDF documents.

My guess is that the project's website is provided via a plugin (headermenu), so a similar plugin hook may be used to provide such an additional link in the RDF.

 

Hope this addresses some of the remarks.

Best regards,

Subscribe to newsletter

You will receive news and links to the most interesting developments...