Rettighetsuttrykk språk - Rights Expression Language

A Rights Expression Language eller REL er et maskinbehandlingsbart språk som brukes til å uttrykke immaterielle rettigheter (for eksempel copyright) og andre vilkår for bruk over innhold. REL kan brukes som frittstående uttrykk (dvs. metadata som kan brukes til søk, kompatibilitetssporing) eller i et DRM- system.

REL-er kan uttrykkes på et maskinspråk (som XML , RDF , RDF-skjema og JSON). Selv om REL-er kan behandles direkte, kan de også oppstå når de er innebygd som metadata i andre dokumenter, for eksempel e-bøker , bilde- , lyd- eller videofiler.

Merkbare REL-er

Merkbare REL inkluderer:

ccREL: Et RDF-skjema brukt av Creative Commons- prosjektet for å uttrykke lisensene .; Det samme ordforrådet er også vedtatt av GNU Project for å uttrykke deres General Public License (GPL) i maskinlesbar form.

W3C Open Digital Rights Language ODRL: Arbeidsgruppen W3C Permissions and Obligations Expression (POE) har utviklet ODRL-anbefalingene for å uttrykke tillatelser og forpliktelser for digitalt innhold.; W3C ODRL Informasjonsmodell tilbyr et rammeverk for de underliggende begrepene, enhetene og relasjonene som danner grunnlaget for semantikken til ODRL-uttrykk. Målet med ODRL-informasjonsmodellen er å støtte fleksible policyuttrykk ved å tillate forfatteren å inkludere så mye, eller så lite, uttrykksfulle detaljer om vilkårene for bruk av aktiva, involverte parter og forpliktelser.; W3C ODRL Vocabulary & Expression beskriver de potensielle begrepene som brukes i ODRL Policy-uttrykk, og hvordan du serieriserer dem. Begrepene er en del av ODRL Ontology og formaliserer semantikken. Det brede settet med ord i vokabularet gir støtte til samfunn til å bruke ODRL som hovedspråk for å uttrykke vanlige brukssaker.

XrML: XrML begynte med arbeidet på Xerox på 1990-tallet. Etter å ha gått gjennom flere versjoner og separate prosjekter, dannet den senere grunnlaget for REL for MPEG-21 .

MPEG-21: Del 5 av denne MPEG- standarden inkluderer en REL.

METSRights: METSRights er et utvidelsesskjema til METS- innpakningsmetadatastandarden.

Bruk av en REL

Funksjonen til en REL er å definere lisenser, og å beskrive disse lisensene i form av tillatelser eller begrensninger de innebærer for hvordan det relaterte innholdet deretter kan brukes.

"Lisens" her kan bety enten:

En "velkjent lisens", for eksempel GFDL , Apache License eller en Creative Commons CC-by-sa-3.0 etc.
En forhåndsdefinert lisens som er som disse, men ikke så kjent. Eksempler kan være proprietære "krympepapir" -lisenser.
En spesifikk lisens som er opprettet med individuelle vilkår og betingelser, for innhold lisensiert fra en part til en annen.

Kjente lisenser

Bruk av en kjent lisens blir ofte valgt for sin entydige enkelhet: GFDL betyr det samme uansett hvem som bruker det. Bruk av eksisterende lisenser unngår også problemene med lisensformidling . Det er også praktisk å bruke en slik lisens, og å kontrollere at et prosjekt overholder den, uten å forstå for mye om hvilken detalj det innebærer. Bare å vite at "GFDL er akseptabelt for dette prosjektet" og "Alle ressurser i dette prosjektet bruker GFDL" er tilstrekkelig. Sånn sett er velkjente lisenser en måte å unngå å måtte bruke en REL for å modellere detaljene i en lisens, navnet bare er nok.

Til tross for dette kan en REL fremdeles være nyttig med disse lisensene. Det gir en maskinbehandlingsbar måte å identifisere lisensen som er i bruk, og unngå navngivningsproblemer og potensielle uklarheter mellom "Apache License" eller "Apache 2.0 License". Forfatterne av disse lisensene krever også et middel for å beskrive deres interne detaljer.

Forhåndsdefinert lisens

Disse ligner på de kjente lisensene, fordi de er definert før bruk og kan brukes på mange lisensforekomster. Forskjellen deres er at ettersom de ikke er kjent, er det også nødvendig å forklare hva hver av dem innebærer, ettersom det alltid er sannsynlig at brukeren møter hver av dem for første gang. En REL gir midler til å gjøre dette.

Å bruke lisensiert innhold i et prosjekt krever nå evaluering av utsagnet, "Er det noen ressurser i dette prosjektet hvis lisens forbyr en betingelse som prosjektet krever, eller krever en tilstand som prosjektet ikke kan tillate?". Disse kan omfatte en nødvendig evne til å distribuere kopier av prosjektet i etterkant, eller en betingelse for akkreditering på en sprutskjerm som kan være uakseptabel for noen prosjekter.

I programvareutvikling med åpen kildekode er det også vanlig at prosjekter lager sin egen lisens under sitt eget prosjektnavn, men at detaljene i denne lisensen er en kopi av en kjele fra en kjent lisens, eller til og med en referanse til denne lisensen. En REL bør støtte dette ved å gi et middel for lisenser som skal defineres ved å underklasse eksisterende lisenser og muligens endre atferd. Mange av disse lisensene er ikke mer enn forfengelisenser , selv om andre avhengige prosjekter fortsatt må kunne jobbe med dem.

Spesifikke lisenser

Dette er lisenser som opprettes etter behov, for bestemte deler av innholdet eller spesifikke sluttbrukere. Dette er vanligvis slik at de kan ha bruksspesifikke betingelser knyttet til seg, for eksempel utløpsdatoer. Selv om disse lisensene kan være basert på en standard kjeleplate, er hver enkelt unik. Å referere til dem ved navn kunne ikke fungere ettersom det ikke er noe enkelt, stabilt navn. Det er derfor nødvendig å bruke en REL for å uttrykke hver enkelt når det gjelder individuelle egenskaper.

Eksempler kan omfatte en tidsbegrenset kontrakt for å se TV-sport i en måned, betalt av en pågående kontrakt, og å se på dette i hjemmet, men ikke for å vise det i en offentlig bar.

Struktur av en REL

En REL kan beleilig bruke en Entity-Attribute-Value-modell , som for RDF , for å strukturere beskrivelsen av en rettighetsmodell. En slik modell uttrykker seg som lister over:

Enheter: Konkrete "ting" eller "klasser", f.eks:

Arbeid / aktiva

Varen som lisensieres.

Tillatelse

Lisensen, spesielt når dette enten er en "velkjent" lisens (hvor mange verk vil bruke en sammenlignbar abstrakt lisens, for eksempel GFDL )

ellers en forekomst av en bestemt lisens, for eksempel avspilling av innhold kjøpt av en bruker.

Sluttbruker / parter

Et middel for å identifisere sluttbrukeren når lisensiering er en spesifikk kontrakt med en person eller et organ, så vel som lisensieringsparten.

Jurisdiksjon

Sjelden oppgitt eksplisitt, men en viktig kvalifisering når det er lokale juridiske variasjoner i IP-lov .

Attributter: "Egenskaper", eller aspekter av hver av disse enhetene, f.eks. For en lisens:

begrensninger

Handlinger som enten er tillatt eller forbudt

Noen REL-er skiller disse begrensningene inn i grupper, ettersom de sannsynlige verdiene for hver er generelt uensartede sett (handlinger som noen ganger kan være forbudt er sjelden obligatoriske)

tillatelser
forbud
krav / plikter (eller plikter)

Verdier: Verdier for disse egenskapene, fra et forhåndsdefinert ordforråd, f.eks. De fire frihetene :

Bruke arbeidet
Studere og modifisere arbeidet
Omfordeling av eksemplarer
Omfordeling av modifiserte kopier
Skriv ut eiendelen

REL definerer sett med medlemmer for hver av disse tre gruppene, og de tillatte forholdene mellom dem. I eksemplet ovenfor kan det være konsepter om lisenser , tillatelser og omfordeling av kopier . Det kan også være forhold, en lisens kan uttrykke forbud , og separat Tillatelse kan gis til å distribuere eksemplarer .

Uttalelser kan deretter avgis ved bruk av REL (disse vil være utenfor selve REL) som:

<cc:License rdf:about="http://example.org/licenses/distribution/">
  <cc:licenseClass rdf:resource="https://creativecommons.org/license/"/>
  <dc:title>FooCo's Distribution Permitted Licence</dc:title>

  <cc:permits rdf:resource="https://creativecommons.org/ns#Distribution"/>
    
</cc:License>

Dette definerer en ny abstrakt lisens, en som tillater videredistribusjon av kopier. Works kan da bruke denne lisensen ved å referere til den,

<p>This web page is licensed under <a rel="license" href="http://example.org/licenses/distribution/" 
    >FooCo's Distribution Permitted Licence</a>.

Merk at selv om denne hypotetiske lisensen "Distribusjon tillatt" har blitt uttrykt ved bruk av Creative Commons REL, er den ikke en Creative Commons-lisens. Den bruker bare begrepene "Lisens", "tillatelse" og "Distribusjon". Selv om det ikke er en av Creative Commons-lisensene som er definert av dette prosjektet, deler den nøyaktig fellestrekk for disse begrepene: "Distribusjon" har nøyaktig samme betydning og juridisk definisjon mellom dem.

Nedenfor W3C ODRL-eksemplet viser en avtale (lisens) fra tildelingsparten for en eiendel som kan vises av en mottaker (bruker), og en annen for å skrive ut aktiva.

{
    "@context": {
    "odrl": "http://www.w3.org/ns/odrl/2/"
    },
    "@type": "odrl:Agreement",
    "@id": "http://example.com/policy:4444",
    "target": "http://example.com/asset:5555",
     "assigner": "http://example.com/MyPix:55",
    "permission": [{
        "assignee": "http://example.com/guest:0001",
        "action": "odrl:display"
    }],
    "permission": [{
        "assignee": "http://example.com/guest:0002",
        "action": "odrl:print"
    }]
}

Samarbeid mellom lisenser

Økende interesse for mashups og samarbeidsprosjekter skaper et behov for å kombinere innhold, og for lisensieringsteknologier som kan støtte dette.

Den enkleste tilnærmingen er å bare kombinere innhold under samme velkjente lisens. Dette er imidlertid overbegrensende, og mange kompatible lisenser kan tillate at innholdet deres blir kombinert . Det er imidlertid vanskelig å bedømme dette, om det er tillatt og hvordan det resulterende innholdet skal lisensieres. Det kan fremdeles være finesser når det er overlappende krav eller Copyleft- problemer. Spesielt Creative Commons 'attribution-sharealike' og 'attribution-noncommercial-sharealike' er inkompatible.

Å kombinere lisenser er enklere hvis alle lisensene som er involvert kan uttrykkes gjennom samme REL. I så fall er det lettere å se når en tillatelse eller et forbud gjelder hvis de i det minste gjelder en identisk definisjon av "Distribusjon". Et åpenbart eksempel på dette er Creative Commons-lisensene , der en lisensfamilie alle er definert i samme REL .

Selv om forskjellige lisenser opprinnelig ble definert gjennom forskjellige REL, kan det være mulig å kode på nytt en lisens samtidig i en annen delt REL, noe som gjør dem sammenlignbare. GPL har nylig blitt uttrykt i ccREL , noe som gir denne fordelen.

Vanskeligheter med å samarbeide mellom lisenser

Bortsett fra spørsmålene om motstridende krav (ovenfor), er det også tekniske problemer med å sammenligne lisenser. Mange av disse blir lindret hvis samme REL kan brukes, selv om lisensene er forskjellige.

Semantikk

Et vanlig problem med semantisk oversettelse mellom skjemaer (som REL) er å sørge for at betydningen av begrepene er identiske. Selv om det semantiske nettet begynner å bruke ontologiverktøy som OWL for å beskrive mening, er den nåværende teknologiske tilstanden for REL mindre avansert enn dette. Enklere behandling, og potensialet for dyre søksmål ellers, betyr at semantikken til REL-er må være helt identisk, ikke bare utledes av en resonnement .

De vanlige problemene er å demonstrere ekvivalensen mellom klasser , egenskaper og forekomster . For RELs er det største problemet for tilfellene , dvs. de presise definisjonene av "Distribusjon", "Share-alike" osv. Klassene og egenskapene er vanligvis enkle begreper og veldig like. Ikke alle REL-er støtter alle klasser: Noen ignorerer jurisdiksjon eller til og med sluttbruker, i henhold til behovene til markedet de ble utviklet for.

Implisitte forutsetninger

Et mindre åpenbart problem ved sammenligning av REL er når de har en annen grunnlinje. Baselinjen definerer vilkårene som lisensen innebærer når det ikke er noen eksplisitte uttalelser inkludert. Noen REL-er bruker fremgangsmåten "Alt ikke tillatt er forbudt", andre (som ccREL) bruker Bernkonvensjonen som utgangspunkt.

Languages

In other projects