-
Notifications
You must be signed in to change notification settings - Fork 4
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Byt till licenser från publication office #100
Comments
Om vi byter ska vi ha med alla 161 som listas, eller bara de 7 vi har i DCAT-AP-SE2? |
Jag är som sagt på mötet spontant emot detta. Det finns redan URI:er för dessa rättighetsmärkningar – att använda EU-specifika sådana istället för dess skapar förvirring och sänker intenoperabilitet, snarare än att främja det. Även om det finns skos:exactMatch-relationer. |
Jag är inne på samma linje som @carwash. Det känns tokigt att hålla sig i den lilla simbassängen EU när det finns en större internationell pool. |
Europeana har återkommit med ett – enligt min åsikt – mycket bra svar, som jag ska försöka sammanfatta här. De har förstås aldrig jobbat med DCAT-AP SE, och inte heller med senaste DCAT-AP 3.0. Däremot har de jobbat med DCAT-AP 2.1 för att leverera datat till data.europa.eu. Detta arbete finns dokumenterat på https://docs.google.com/document/d/17vPxcfnu9VUVUXk9fgv0ZxJ9p5um8qqqN8Xt0dTNbUw/ . De påpekar dock, att även där, de har använt de riktiga URI:erna för t.ex. CC-licenserna, inte URI:erna som Publications Office förespråkar. Det värsta de fick göra i deras mappning var, att explicit deklararera CC0-URI:n som både "licens" och "rättighetsmärkning" av typ "public domain":
De håller med, om att det vore dumt att försöka öka kompatibilitet i ett ekosystem (Europa) på bekostnaden att man därmed bryter kompatibilitet med alla andra. De betraktar Publications Office-vokabulären snarare som en kontrollerad lista på tillåtna licenser/rättighetsmärkningar, inte att man ska tillämpa just deras URI:er. De hänvisar även till DCAT-AP dokumentationen på https://semiceu.github.io/DCAT-AP/releases/3.0.0/#legal-information och citerar följande:
…vilket de tolkar som, att man inte är tvungen att använda Publications Office-URI:erna; snarare, att de ska tillämpas i sådana fall där det finns lokala varianter i praxis kring vilka URI:er man använder – då ska man enas kring NAL-URI:erna. Men att i det vanligare fallet att det finns etablerade välkända URI:er – som det finns för CC-licenserna, PD-mark, och RightsStatements.org – då kan man med fördel använda dem. Jag skulle föreslå, att vi absolut förhåller oss till de rättighetsmärkningarna som finns med i Publications Office-vokabulären, men att vi fortsätter använda deras "riktiga" URI:er, och bara vänder oss till de av vokabuläreren tilldelade URI:erna när ingen annan URI finns för rättighetsmärkningen. |
En liten undersökning visar att förutom CC licenser så är två datamängder som använder: I övrigt är det 15 st. specifika licenser från trafiklabb med två datamänder vardera. Så slutsatsen att behovet för att kunna välja andra licenser från publication office lista minimal. |
Att ange rättighetsmärkningar för CC licenser är onödigt. De är välkända och varje aktör bör inte ge sig på att kategorisera CC-BY för sig, det kommer bara ge upphov till en uppsjö av felaktiga kategoriseringar. Enbart om man väljer att ange en egen licens, som t.ex. trafiklab gjort, bör man kategorisera explicit. |
Förslaget är att avslå denna ändring men att förklara att om man av någon anledning vill använda NAL så är man fri att göra det. På dataportal.se kommer vi skriva om så att NAL licenser och CC licenser som sammanfaller behandlas utan att det blir duplikat i sökningen. |
Contact Details
No response
What benefits does the suggestion solve?
För att öka interoperabiliteten i EU bör vi använda samma URI:er för välkända licenser.
Feature suggestion description
Vi byter ut den lista med creative commons licenser mot de som definierats av publication office: https://op.europa.eu/en/web/eu-vocabularies/dataset/-/resource?uri=http://publications.europa.eu/resource/dataset/licence
Alternative solutions
No response
Additional information
No response
The text was updated successfully, but these errors were encountered: