Here is a list of users from gwdg with mapping to their respective github users. (partial) https://docs.google.com/spreadsheets/d/1dqyiJItJafXx6Kw_aX6fkqbuwbDUHeS0bmJvKC_RUik/edit#gid=0
I will ask again the colleagues to provide their github-user, otherwise we can look for the equivalencies ourselves. In the worst case, I guess, we can also map multiple users to one default user?
(notify @p.dpancic)
Look at this in Editorial Board and make decision: good as is. or more fields to map (if so, propose) Frontend can implement whatever mapping is proposed.
it was an backend issue. Should be resolved with latest version now.
seems related to #169 (closed)
Yes, let's remove it.
I may be overlooking something, but in my understanding
during ingest there already is a lookup mechanism based on item.sourceItemId
.
And in when creating an item accessibleAt
could be compared to existing accessibleAt
to avoid lookups,
but I don'T see added value of mixing those two.
And I don't at all understand why this check happens during merge?
So in my naive opinion the check should be simply removed.
We want to move away from gitlab.gwdg.de to github.com under own organisation sshomp We migrate all repos https://gitlab.gwdg.de/sshoc except:
Not sure about the status of /need for Cluster Management
currently the production deploy still has the pre-seeded passwords for Administrator/Moderator/Contributor. we should change these, as they have circulated rather widely.
Given that the application is running on ACDH-CH, we could apply the local policy for managing passwords, i.e. letting the SysAdmins know, who keep it in a safe and secret location.
Taking up the old threads - How are we here, @alex ?
we should have a mapping of marketplace entities (and their properties) to schema.org. we can then include jsonld metadata on the item detail pages.
i have started with MPDataset, help apprectiated:
Dataset | dataset |
---|---|
label | headline |
description | abstract |
description | description |
accessibleAt | url |
??? | includedInDataCatalog |
properties: keyword | about |
licenses: label | license |
version | version |
contributor: actor.name | contributor |
dateCreated | dateCreated |
dateLastUpdated | dateModified |
properties: language | inLanguage |
we should have a mapping of marketplace entities (and their properties) to schema.org. we can then include jsonld metadata on the item detail pages.
i have started with MPDataset, help apprectiated:
Dataset | dataset |
---|---|
label | headline |
description | abstract |
description | description |
accessibleAt | url |
??? | includedInDataCatalog |
properties: keyword | about |
licenses: label | license |
version | version |
contributor: actor.name | contributor |
dateCreated | dateCreated |
dateLastUpdated | dateModified |
properties: language | inLanguage |
When suggesting an item as a contributor, this item will show up in the "My contributed items"-section in the "My account"-part. But when a moderator is approving this item, the item disappears from the "My contributed items"-section, as the moderator is now the "owner" of the item. For a contributor it could be irritating to lose the connection to a contributed item. Imaging spending a lot of time to suggest a new item and then having no single access point where you can see all your contributed items. At least the label "My contributed items" needs to be reviewed for contributors, if we stay with the current approach.
Opinions? @matej.durco @lbarbot @edward.gray @stefan.probst
When suggesting an item as a contributor, this item will show up in the "My contributed items"-section in the "My account"-part. But when a moderator is approving this item, the item disappears from the "My contributed items"-section, as the moderator is now the "owner" of the item. For a contributor it could be irritating to lose the connection to a contributed item. Imaging spending a lot of time to suggest a new item and then having no single access point where you can see all your contributed items. At least the label "My contributed items" needs to be reviewed for contributors, if we stay with the current approach.
Opinions? @matej.durco @lbarbot @edward.gray @stefan.probst
There is a problem with tapor data regarding licensing: they only have information about license type, not the specific license.
We take the information as it is in tapor (in a separate property @license-type@).
However ideally, we need information about the precise license under which given resource is available. This requires a separate curation work, where we revisit the tools and fill the specific license.
(notify: @lbarbot, @ymoranv, @klaus.illmayer, @sotiris.karampatakis, @clara.petitfils, @frank.fischer01)
There is a problem with tapor data regarding licensing: they only have information about license type, not the specific license.
We take the information as it is in tapor (in a separate property @license-type@).
However ideally, we need information about the precise license under which given resource is available. This requires a separate curation work, where we revisit the tools and fill the specific license.
(notify: @lbarbot, @ymoranv, @klaus.illmayer, @sotiris.karampatakis, @clara.petitfils, @frank.fischer01)
The problem of resolving diferences between versions should be solved server-side with update conflict mechanism sshoc-marketplace-backend#85 Now we need to test, if it does what we want it to.
For this we decided following procedure:
S
for one of our ingest pipelinesS
into devx
on some items I
from S
in the marketplacey
to the same items I
directly in S
.S
using methods described in sshoc-marketplace-backend#85
I
(join the evaluation party: @anowak, @klaus.illmayer, @lbarbot, @matej.durco )
The problem of resolving diferences between versions should be solved server-side with update conflict mechanism sshoc-marketplace-backend#85 Now we need to test, if it does what we want it to.
For this we decided following procedure:
S
for one of our ingest pipelinesS
into devx
on some items I
from S
in the marketplacey
to the same items I
directly in S
.S
using methods described in sshoc-marketplace-backend#85
I
(join the evaluation party: @anowak, @klaus.illmayer, @lbarbot, @matej.durco )
ok, for current data Laure corrected manually. But this is still open to be implemented as functionality in DACE.
item label
s should trim leading whitespace (so they are sorted correctly). not sure if this should be handled by backend, or by ingestion.
example (note the leading space):
curl "https://marketplace-api.sshopencloud.eu/api/tools-services/qKSdjk" | jq '.label'
" Automatic Verification Tool (AVT)"