ODRL 정보 모델 2.2

2.1.1 Set 클래스

Set 하위 클래스의 ODRL Policy는 Rules의 모든 조합을 나타냅니다. Set Policy 하위 클래스는 Policy의 기본 하위 클래스이기도 합니다(아무것도 지정되지 않은 경우).

예제 사용 사례: 아래 Set Policy는 대상 Asset http//example.com/asset:9898.movie을 use할 수 있는 Permission을 보여 줍니다.

{
    "@context": "http://www.w3.org/ns/odrl.jsonld",
    "@type": "Set",
    "uid": "http://example.com/policy:1010",
    "permission": [{
        "target": "http://example.com/asset:9898.movie",
        "action": "use"
    }]
}

2.1.2 Offer 클래스

Offer 하위 클래스의 ODRL Policy는 assigner Parties로부터 제공되는 Rules를 나타냅니다. Offer는 일반적으로 더 넓은 대상에게 Policies를 제공하는 데 사용되지만, 어떤 Rules도 부여하지는 않습니다.

Offer 하위 클래스의 ODRL Policy는:

• 동일한 Rules에서 기능적 역할을 나타내기 위해 assigner 속성 값(Party 유형)을 하나 가져야(MUST) 합니다.

참고: 기능적 역할에 대한 자세한 내용은 Function Property 섹션을 참조하십시오.

참고: 위 속성 카디널리티는 규범적 ODRL 정보 모델을 반영합니다. 일부 경우에는 일부 속성의 반복 출현도 지원되지만(Policy Rule Composition 및 Compact Policy에 설명됨), 규범적 원자 Policy는 위 속성 카디널리티와 일관됩니다.

예제 사용 사례: 아래 Offer Policy(이전 예제 기반)는 assigner Party http://example.com/party:org:abc로부터 대상 Asset http//example.com/asset:9898.movie을 play할 수 있는 Permission을 보여 줍니다.

{
    "@context": "http://www.w3.org/ns/odrl.jsonld",
    "@type": "Offer",
    "uid": "http://example.com/policy:1011",
    "profile": "http://example.com/odrl:profile:01",
    "permission": [{
        "target": "http://example.com/asset:9898.movie",
        "assigner": "http://example.com/party:org:abc",
        "action": "play"
    }]
}

2.1.3 Agreement 클래스

Agreement 하위 클래스의 ODRL Policy는 assigner에서 assignee Parties로 부여된 Rules를 나타냅니다. Agreement는 일반적으로 Parties 사이에서 Rules의 조건을 부여하는 데 사용됩니다.

Agreement 하위 클래스의 ODRL Policy는:

• 동일한 Rules에서 기능적 역할을 나타내기 위해 assigner 속성 값(Party 유형)을 하나 가져야(MUST) 합니다.
• 동일한 Rules에서 기능적 역할을 나타내기 위해 assignee 속성 값(Party 유형)을 하나 가져야(MUST) 합니다.

참고: 기능적 역할에 대한 자세한 내용은 Function Property 섹션을 참조하십시오.

참고: 위 속성 카디널리티는 규범적 ODRL 정보 모델을 반영합니다. 일부 경우에는 일부 속성의 반복 출현도 지원되지만(Policy Rule Composition 및 Compact Policy에 설명됨), 규범적 원자 Policy는 위 속성 카디널리티와 일관됩니다.

예제 사용 사례: 아래 Agreement Policy(이전 예제 기반)는 assigner Party http://example.com/party:org:abc로부터 assignee Party http://example.com/party:person:billie에게 대상 Asset http//example.com/asset:9898.movie을 play할 수 있는 Permission을 부여하는 것을 보여 줍니다.

{
    "@context": "http://www.w3.org/ns/odrl.jsonld",
    "@type": "Agreement",
    "uid": "http://example.com/policy:1012",
    "profile": "http://example.com/odrl:profile:01",
    "permission": [{
        "target": "http://example.com/asset:9898.movie",
        "assigner": "http://example.com/party:org:abc",
        "assignee": "http://example.com/party:person:billie",
        "action": "play"
    }]
}

2.2.1 Relation 속성

추상 relation 속성은 Action과 Asset 사이에 명시적 링크를 만들어, Asset이 이를 연결하는 Rule과 관련하여 어떻게 사용되어야(MUST) 하는지를 나타내는 데 사용됩니다.

ODRL validator는 다음 relation의 하위 속성을 지원해야 (MUST) 합니다:

• target: Asset이 Rule action이 직접 적용되는 주요 대상임을 나타냅니다.

추가 relation 하위 유형 속성은 ODRL Common Vocabulary [odrl-vocab] 및 ODRL Profiles에서 정의될 수 (MAY) 있습니다.

예제 사용 사례: assigner Party http//example.com/party:0001가 target Asset http://example.com/asset:3333을 표시하도록 제안합니다.

{
   "@context": "http://www.w3.org/ns/odrl.jsonld",
   "@type": "Offer",
   "uid": "http://example.com/policy:3333",
   "profile": "http://example.com/odrl:profile:02",
   "permission": [{
       "target": "http://example.com/asset:3333",
       "action": "display",
       "assigner": "http://example.com/party:0001"
   }]
}

예제 사용 사례: 아래 Policy는 target Asset http://example.com/archive1011에 대한 index action Permission을 보여 줍니다. target asset은 해당 리소스가 리소스 컬렉션임을 나타내기 위해 AssetCollection으로도 선언됩니다. 추가 Asset relation summary는 인덱싱 출력이 저장되어야 하는 Asset http://example.com/x/database를 나타냅니다. ODRL Profile ttp://example.com/odrl:profile:03은 이 새로운 relation 하위 속성을 정의합니다.

{
   "@context": "http://www.w3.org/ns/odrl.jsonld",
   "@type": "Policy",
   "uid": "http://example.com/policy:1011",
   "profile": "http://example.com/odrl:profile:03",
   "permission": [{
       "target": {
           "@type": "AssetCollection",
           "uid":  "http://example.com/archive1011" },
       "action": "index",
       "summary": "http://example.com/x/database"
   }]
}

2.2.2 Part Of 속성

partOf 속성은 Asset 리소스가 멤버로 속해 있는 AssetCollection을 식별하는 데 사용됩니다. 목적은 Assets와 AssetCollections 사이의 멤버십 관계를 명시적으로 표현하는 것입니다. 이를 통해 AssetCollection과 관련된 Rule이 해당 Rule이 적용될 수 있는 개별 Assets가 무엇인지 이해할 수 있습니다. 또한 Asset/AssetCollection 멤버십 관계는 Rules의 충돌을 잠재적으로 감지할 수 있습니다.

예제 사용 사례: 아래 스니펫은 문서를 설명하는 일부 Dublin Core 메타데이터를 보여 줍니다. odrl:partOf 속성은 Asset http://example.com/asset:111.doc이 위 예제의 Policy에서 사용되는 http://example.com/archive1011 AssetCollection의 멤버임을 명시합니다. 이는 http://example.com/asset:111.doc이 Policy의 target Assets 중 하나이며 인덱싱될 수 있음을 의미합니다.

{
   "@type": "dc:Document",
   "@id": "http://example.com/asset:111.doc",
   "dc:title": "Annual Report",
   ...
   "odrl:partOf": "http://example.com/archive1011",
   ...
}

2.2.3 Target Policy 속성

ODRL Policy 클래스는 hasPolicy 속성에 의해 참조될 수도 (MAY) 있습니다. 이는 ODRL Policy Rules가 외부 메타데이터 표현(Asset을 식별하는 표현)의 객체가 되는 것을 지원합니다. hasPolicy가 메타데이터 표현과 ODRL Policy 사이에 명시되었을 때, 식별되는 Asset은 해당 Policy의 모든 Rules의 target Asset으로 추론되어야 (MUST) 합니다. Policy에 여러 Rules가 있는 경우, 추론된 Asset은 Policy의 모든 Rule에 대한 target Asset이 됩니다.

예제 사용 사례: 아래 스니펫은 영화 Asset을 설명하는 일부 Dublin Core 메타데이터를 보여 줍니다. odrl:hasPolicy 속성은 ODRL Policy http://example.com/policy:1010(위에서 설명한 Set Policy)에 연결됩니다. 이 경우 Asset http://example.com/asset:9999.movie는 이제 Policy http://example.com/policy:1010의 Permission에 대한 target Asset이기도 합니다. 이 Policy에 추가 Rules가 있다면, 동일한 Asset이 각 Rule의 target Asset이 됩니다.

{
   "@type": "dc:MovingImage",
   "@id": "http://example.com/asset:9999.movie",
   "dc:publisher": "ABC Pictures",
   "dc:creator": "Allen, Woody",
   "dc:issued": "2017",
   "dc:subject": "Musical Comedy",
   ...
   "odrl:hasPolicy": "http://example.com/policy:1010",
   ...
}

2.3.1 Function 속성

function 속성은 Rule을 Party에 연결하여, 이를 연결하는 Rule과 관련하여 Party가 수행하는 기능을 나타내는 데 사용됩니다. function 속성 자체는 추상적이며, 하위 속성은 Party와 Rule 사이의 기능적 역할에 대한 명시적 의미론을 나타냅니다.

ODRL validator는 다음 function의 하위 속성을 지원해야 (MUST) 합니다:

• assigner: Rule을 발행하는 Party를 나타냅니다. 예를 들어 Permission을 부여하거나 합의된 Duty의 이행을 요구하는 Party입니다.
• assignee: Rule의 수신자인 Party를 나타냅니다. 예를 들어 Permission을 부여받거나 합의된 Duty를 이행해야 하는 Party입니다.

추가 function 하위 유형 속성은 ODRL Common Vocabulary [odrl-vocab] 및 ODRL Profiles에서 정의될 수 (MAY) 있습니다.

예제 사용 사례: 이 Policy는 assigner와 assignee의 기능적 역할을 가진 두 Parties가 포함된 Agreement를 보여 줍니다. assigner는 assignee에게 target asset에 대한 play action을 부여합니다.

{
    "@context": "http://www.w3.org/ns/odrl.jsonld",
    "@type": "Agreement",
    "uid": "http://example.com/policy:8888",
    "profile": "http://example.com/odrl:profile:04",
    "permission": [{
        "target": "http://example.com/music/1999.mp3",
        "assigner": "http://example.com/org/sony-music",
        "assignee": "http://example.com/people/billie",
        "action": "play"
    }]
}  

예제 사용 사례: 이 Policy는 assigner와 assignee의 기능적 역할을 가진 두 Parties가 포함된 Agreement를 보여 줍니다. assigner는 assignee에게 target asset의 사용을 부여합니다. 이 경우 assigner는 Party이자 vcard:Organisation 및 일부 추가 외부 속성으로 명시적으로 선언됩니다. assignee는 PartyCollection이자 vcard:Group 및 일부 추가 외부 속성으로 명시적으로 선언됩니다. 이는 http://example.com/team/A로 식별되는 모든 엔터티가 각각 동일하게 부여된 action을 갖게 됨을 의미합니다

{
    "@context": [
        "http://www.w3.org/ns/odrl.jsonld",
        { "vcard": "http://www.w3.org/2006/vcard/ns#" }
    ],
    "@type": "Agreement",
    "uid": "http://example.com/policy:777",
    "profile": "http://example.com/odrl:profile:05",
    "permission": [{
        "target": "http://example.com/looking-glass.ebook",
        "assigner": {
            "@type": [ "Party", "vcard:Organization" ],
            "uid":  "http://example.com/org/sony-books",
            "vcard:fn": "Sony Books LCC",
            "vcard:hasEmail": "sony-contact@example.com" },
        "assignee": {
            "@type": [ "PartyCollection", "vcard:Group" ],
            "uid":  "http://example.com/team/A",
            "vcard:fn": "Team A",
            "vcard:hasEmail": "teamA@example.com"},
        "action": "use"
    }]
}  

2.3.2 Part Of 속성

partOf 속성은 Party 엔터티가 멤버로 속해 있는 PartyCollection을 식별하는 데 사용됩니다. 목적은 Parties와 PartyCollections 사이의 멤버십 관계를 명시적으로 표현하는 것입니다. 이를 통해 PartyCollection과 관련된 Rule이 해당 Rule이 적용될 수 있는 개별 Parties가 무엇인지 이해할 수 있습니다. 또한 Party/PartyCollection 멤버십 관계는 Rules의 충돌을 잠재적으로 감지할 수 있습니다.

예제 사용 사례: 아래 스니펫은 Party를 설명하는 일부 vCard 메타데이터를 보여 줍니다. odrl:partOf 속성은 Party http://example.com/person/murphy가 위 예제의 Policy에서 사용되는 http://example.com/team/A PartyCollection의 멤버임을 명시합니다. 이는 http://example.com/person/murphy가 assignee이며 Policy의 target asset을 사용할 수 있음을 의미합니다.

{
   "@type": "vcard:Individual",
   "@id": "http://example.com/person/murphy",
   "vcard:fn": "Murphy",
   "vcard:hasEmail": "murphy@example.com",
   ...
   "odrl:partOf": "http://example.com/team/A",
   ...
}

2.3.3 Assigned Policy 속성

ODRL Policy 클래스는 assignerOf 및 assigneeOf 속성에 의해 참조될 수도(MAY) 있습니다. 이는 ODRL Policy Rules가 외부 메타데이터 표현(Party를 식별하는 표현)의 객체가 되는 것을 지원합니다. assignerOf가 메타데이터 표현과 ODRL Policy 사이에 명시되었을 때, 식별되는 Party는 해당 Policy의 모든 Rules에서 assigner 기능적 역할을 수행하는 것으로 추론되어야(MUST) 합니다. assigneeOf가 메타데이터 표현과 ODRL Policy 사이에 명시되었을 때, 식별되는 Party는 해당 Policy의 모든 Rules에서 assignee 기능적 역할을 수행하는 것으로 추론되어야(MUST) 합니다. Policy에 여러 Rules가 있는 경우, 추론된 Party는 Policy의 모든 Rule에 대해 기능적 역할을 수행합니다.

예제 사용 사례: 아래 스니펫은 individual Party를 설명하는 일부 vCard 메타데이터를 보여 줍니다. odrl:assigneeOf 속성은 ODRL Policy http://example.com/policy:1011(위에서 설명한 Offer Policy)에 연결됩니다. 이 경우 Party http://example.com/person/billie는 이제 Policy http://example.com/policy:1011의 Permission에 대한 assignee이기도 합니다. 이 Policy에 추가 Rules가 있다면, 동일한 Party가 각 Rule의 assignee가 됩니다.

{
   "@type": "vcard:Individual",
   "@id": "http://example.com/person/billie",
   "vcard:fn": "Billie",
   "vcard:hasEmail": "billie@example.com",
   ...
   "odrl:assigneeOf": "http://example.com/policy:1011",
   ...
}

2.5.1 Constraint 클래스

Constraint 클래스는 하나의 관계 연산자로 두 operands(Constraints가 아닌 것)를 비교하는 표현식에 사용됩니다. 비교가 일치하면 Constraint는 충족되고, 그렇지 않으면 충족되지 않습니다. Constraint 클래스는 예를 들어 사용 횟수(leftOperand)가 숫자 10(rightOperand)보다 작아야 한다(operator)는 식의 비교 표현식을 공식화합니다.

Constraint 클래스에는 다음 속성이 있습니다:

• Constraint는 Constraint를 식별하기 위해 uid 속성 값(IRI [rfc3987] 유형)을 없거나 하나 가질 수(MAY) 있습니다.
• Constraint는 LeftOperand 유형의 leftOperand 속성 값을 하나 가져야(MUST) 합니다.
• Constraint는 Operator 유형의 operator 속성 값을 하나 가져야(MUST) 합니다.
• Constraint는 다음 중 하나를 가져야(MUST) 합니다:
  • 다음 유형의 rightOperand 속성 값 하나:
    • 리터럴, 또는 IRI [rfc3987], 또는 RightOperand; 또는
    • 집합 기반 operators의 경우, 리터럴 목록, 또는 IRI 목록 [rfc3987], 또는 RightOperands 목록;
  • 다음 유형의 rightOperandReference 속성 값 하나:
    • IRI [rfc3987]; 또는
    • 집합 기반 operators의 경우, IRI 목록 [rfc3987];
    right operand 값에 대한 참조.
• Constraint는 rightOperand/Reference의 데이터 유형을 위한 dataType 속성 값을 없거나 하나 가질 수(MAY) 있습니다.
• Constraint는 rightOperand/Reference 값에 사용되는 단위를 설정하기 위해 unit 속성 값(IRI [rfc3987] 유형)을 없거나 하나 가질 수(MAY) 있습니다.
• Constraint는 leftOperand action에서 생성된 값 또는 leftOperand와 관련되어 비교의 참조로 설정된 값을 위한 status 속성 값을 없거나 하나 가질 수 (MAY) 있습니다.

leftOperand 속성 값은 LeftOperand 클래스의 인스턴스로 정의됩니다. leftOperand 인스턴스는 Constraint의 의미론을 나타내도록 명확히 정의되어야(MUST) 하며, 비교할 값을 어떻게 검색하거나 생성해야 하는지를 선언할 수(MAY) 있습니다. ODRL Common Vocabulary [odrl-vocab]는 ODRL Profiles가 사용할 수(MAY) 있는 leftOperand들을 정의합니다.

operator 속성 값은 Operator 클래스의 인스턴스로 정의됩니다. operator 인스턴스는 left operand와 right operand 사이의 “보다 큼” 또는 “같음”과 같은 관계 연산을 식별합니다.

rightOperand 속성 값은 RightOperand 클래스의 인스턴스, IRI 또는 Literal 값으로 정의됩니다. rightOperand는 leftOperand와 비교될 Constraint의 값입니다. rightOperandReference는 rightOperand의 실제 값을 얻기 위해 먼저 역참조되어야(MUST) 하는 IRI를 나타냅니다. rightOperandReference는 rightOperand의 값을 먼저 IRI 역참조를 통해 얻어야(MUST) 하는 경우에 사용됩니다. Constraint에는 rightOperand 또는 rightOperandReference 중 하나만 나타나야(MUST) 합니다.

rightOperand는 값을 나타내고, rightOperandReference는 값을 얻기 위해 역참조해야 하는 IRI를 나타냅니다. rightOperand가 http://example.com/c100이라면, 이는 표현식에서 비교할 값으로 해석됩니다. rightOperandReference가 동일한 값인 http://example.com/c100이라면, 해당 IRI를 먼저 역참조해야 하며 반환된 데이터는 표현식에서 비교할 값으로 해석되어야 합니다.

dataType은 xsd:decimal 또는 xsd:datetime과 같은  rightOperand/Reference의 유형을 나타내며, unit은 “EU 통화”와 같은 rightOperand/Reference의 단위 값을 나타냅니다.

status는 비교 표현식에서 사용되어야(MUST) 하는, leftOperand action에서 생성된 값을 제공합니다. 예를 들어, count constraint가 rightOperand 값 10과 status 값 5를 가질 수 있습니다. 이는 action이 이미 5번 수행되었으며, 비교에서는 현재 action을 status 값과 비교해야 함을 의미합니다.

2.5.2 Logical Constraint 클래스

Logical Constraint 클래스는 기존 Constraints인 두 개 이상의 operands를 하나의 논리 연산자로 비교하는 표현식에 사용됩니다. 비교가 논리적으로 일치하면 Logical Constraint는 충족되고, 그렇지 않으면 충족되지 않습니다. 예를 들어, 세 Constraints가 논리적으로 and 처리되어 세 가지 모두가 참이어야 Logical Constraint가 충족됨을 나타낼 수 있습니다.

Logical Constraint 클래스에는 다음 속성이 있습니다:

• Logical Constraint는 Logical Constraint를 식별하기 위해 uid 속성 값(IRI [rfc3987] 유형)을 없거나 하나 가질 수(MAY) 있습니다.
• Logical Constraint는 비교되는 기존 constraints의 논리적 관계를 나타내는 operand 하위 속성을 하나 가져야(MUST) 하며, 그 값은 기존 Constraint 인스턴스의 목록입니다.

ODRL evaluator는 다음 operand의 하위 속성을 지원해야 (MUST) 합니다:

• or - Constraints 중 적어도 하나가 충족되어야(MUST) 합니다
• xone - Constraints 중 하나만, 그리고 그 이상은 아니게 충족되어야(MUST) 합니다
• and - Constraints 모두가 충족되어야(MUST) 합니다
• andSequence - Constraints 모두가 순서대로 충족되어야(MUST) 합니다

추가 operand 하위 속성은 ODRL Profiles에 의해 정의될 수 (MAY) 있습니다.

Logical Constraints에 대한 ODRL 검증 요구 사항에는 다음이 포함됩니다:

1. operand는 or, xone, and, andSequence 하위 속성 중 하나여야(MUST) 합니다. 추가 operand 하위 속성은 Logical Constraints의 사용만을 위해 ODRL Profiles에 의해 정의될 수(MAY) 있습니다.
2. 모든 operand 값은 고유한 Constraint 인스턴스여야(MUST) 합니다.

Constraint 인스턴스는 평가되어야(MUST) 하며, 그 결과는 (operand 하위 속성의 의미론에 따라) 논리적 관계가 충족되는지 판단하는 데 사용됩니다.

2.5.3 Rule을 가진 Constraint 속성

Rule(Permission, Prohibition 또는 Duty 등)은 Rule에 대한 조건을 나타내기 위해 constraint 속성을 포함할 수(MAY) 있습니다. 이 조건을 충족하려면, constraint 속성이 참조하는 모든 Constraints/Logical Constraints가 충족되어야(MUST) 합니다.

예제 사용 사례: 아래 Policy Offer 예제에서 permission은 target asset이 distribute될 수 있도록 허용하며, permission이 2018-01-01까지만 수행될 수 있다는 dateTime 조건의 constraint를 포함합니다.

{
    "@context": "http://www.w3.org/ns/odrl.jsonld",
    "@type": "Offer",
    "uid": "http://example.com/policy:6163",
    "profile": "http://example.com/odrl:profile:10",
    "permission": [{
       "target": "http://example.com/document:1234",
       "assigner": "http://example.com/org:616",
       "action": "distribute",
       "constraint": [{
           "leftOperand": "dateTime",
           "operator": "lt",
           "rightOperand":  { "@value": "2018-01-01", "@type": "xsd:date" }
       }]
   }]
}

2.5.4 Action을 가진 Refinement 속성

Action은 Action 연산의 의미론을 직접 좁히는 Constraint/Logical Constraint를 나타내기 위해 refinement 속성을 포함할 수(MAY) 있습니다. Action에 대한 더 좁은 의미론이라는 이 조건을 충족하려면, refinement 속성이 참조하는 모든 Constraints/Logical Constraints가 충족 상태를 생성하는 데 사용되어야(MUST) 합니다.

참고: Action에 refinements를 적용한 결과는 null 연산이 되어서는 안 됩니다(SHOULD NOT).

예제 사용 사례: 아래 Policy Offer 예제에서 permission은 target asset이 print될 수 있도록 허용하며, 1200 dpi 이하의 해상도라는 refinement Constraint도 포함합니다. 이 refinement는 더 좁은 인쇄 의미론, 이 경우 특정 최대 해상도 수준에서의 인쇄를 나타냅니다.

{
    "@context": "http://www.w3.org/ns/odrl.jsonld",
    "@type": "Offer",
    "uid": "http://example.com/policy:6161",
    "profile": "http://example.com/odrl:profile:10",
    "permission": [{
       "target": "http://example.com/document:1234",
       "assigner": "http://example.com/org:616",
       "action": [{
          "rdf:value": { "@id": "odrl:print" },
          "refinement": [{
             "leftOperand": "resolution",
             "operator": "lteq",
             "rightOperand": { "@value": "1200", "@type": "xsd:integer" },
             "unit": "http://dbpedia.org/resource/Dots_per_inch"
          }]
      }]
   }]
}

예제 사용 사례: 아래 Policy는 target asset을 온라인 미디어 또는 인쇄 미디어를 통해 둘 중 하나로 복제할 수 있지만 둘 다는 아님을 보여 줍니다. 이는 다른 곳에 선언된 두 기존 Constraints를 참조하는 Logical Constraint(xone operand 사용)로 표현됩니다.

{
    "@context": "http://www.w3.org/ns/odrl.jsonld",
    "@type": "Offer",
    "uid": "http://example.com/policy:88",
    "profile": "http://example.com/odrl:profile:10",
    "permission": [{
        "target": "http://example.com/book/1999",
        "assigner": "http://example.com/org/paisley-park",
        "action": [{
           "rdf:value": { "@id": "odrl:reproduce" },
           "refinement": {
               "xone": { 
	           "@list": [ 
		       { "@id": "http://example.com/p:88/C1" },
                       { "@id": "http://example.com/p:88/C2" } 
		   ]
	       }
            }
        }]
    }]
}
 
{
   "@context": "http://www.w3.org/ns/odrl.jsonld",
   "@type": "Constraint",
   "uid": "http://example.com/p:88/C1",
   "leftOperand": "media",
   "operator": "eq",
   "rightOperand": { "@value": "online", "@type": "xsd:string" }
}
 
{
   "@context": "http://www.w3.org/ns/odrl.jsonld",
   "@type": "Constraint",
   "uid": "http://example.com/p:88/C2",
   "leftOperand": "media",
   "operator": "eq",
   "rightOperand": { "@value": "print", "@type": "xsd:string" }
}

2.5.5 Asset Collection을 가진 Refinement 속성

AssetCollection은 전체 컬렉션의 개별 Asset(s)을 식별할 refinement 맥락을 나타내기 위해 refinement 속성을 포함할 수(MAY) 있습니다. refinement 속성은 컬렉션의 각 멤버의 특성에 적용됩니다(리소스 전체에는 적용되지 않음). 전체 AssetCollection의 개별 Asset(s)을 식별하는 이 조건을 충족하려면, refinement 속성이 참조하는 모든 Constraints/Logical Constraints가 충족되어야(MUST) 합니다.

참고: AssetCollection에 refinements를 적용한 결과는 null 집합이 되어서는 안 됩니다(SHOULD NOT).

refinement 속성을 사용할 때에는 uid 속성을 사용하여 AssetCollection을 식별해서는 안 됩니다(MUST NOT). 대신 source 속성을 사용하여 AssetCollection을 참조해야(MUST) 합니다.

예제 사용 사례: Policy는 멀티미디어 비디오의 AssetCollection인 target source http://example.com/media-catalogue를 정의합니다. target에는 AssetCollection 멤버의 특성을 지정하는 refinement도 있습니다. 이 경우 target Assets의 하위 집합은 running time이 60분 미만인 것들이며, 이들 각각은 재생될 수 있습니다. runningTime leftOperand는 play action과 함께 ODRL Profile http://example.com/odrl:profile:11에 정의되어 있음을 유의하십시오.

{
  "@context": "http://www.w3.org/ns/odrl.jsonld",
  "@type": "Offer",
  "uid": "http://example.com/policy:4444",
  "profile": "http://example.com/odrl:profile:11",
  "permission": [{
    "assigner": "http://example.com/org88",
    "target": {
      "@type": "AssetCollection",
      "source":  "http://example.com/media-catalogue",
      "refinement": [{
        "leftOperand": "runningTime",
        "operator": "lt",
        "rightOperand": { "@value": "60", "@type": "xsd:integer" },
        "unit": "http://qudt.org/vocab/unit/MinuteTime"
      }]
    },
    "action": "play"
  }]
}

2.5.6 Party Collection을 가진 Refinement 속성

PartyCollection은 전체 컬렉션의 개별 Party(ies)를 식별할 refinement 맥락을 나타내기 위해 refinement 속성을 포함할 수(MAY) 있습니다. refinement 속성은 컬렉션의 각 멤버의 특성에 적용됩니다(리소스 전체에는 적용되지 않음). 전체 PartyCollection의 개별 Party(ies)를 식별하는 이 조건을 충족하려면, refinement 속성이 참조하는 모든 Constraints/Logical Constraints가 충족되어야(MUST) 합니다.

참고: PartyCollection에 refinements를 적용한 결과는 null 집합이 되어서는 안 됩니다(SHOULD NOT).

refinement 속성을 사용할 때에는 uid 속성을 사용하여 PartyCollection을 식별해서는 안 됩니다(MUST NOT). 대신 source 속성을 사용하여 PartyCollection을 참조해야(MUST) 합니다.

예제 사용 사례: target Asset http://example.com/myPhotos:BdayParty는 사진의 assigner인 http://example.com/user44가 소셜 네트워크 사이트에 게시한 사진들의 집합입니다. assignee source는 PartyCollection http://example.com/user44/friends이며 assigner의 모든 친구를 나타냅니다. assignee에는 또한 컬렉션 멤버 중 foaf:age가 18을 초과하는 사람에게만 ex:view permission(Profile에 의해 정의됨)이 할당됨을 나타내는 refinement가 있습니다.

{
  "@context": "http://www.w3.org/ns/odrl.jsonld",
  "@type": "Agreement",
  "uid": "http://example.com/policy:4444",
  "profile": "http://example.com/odrl:profile:12",
  "permission": [{
    "target": "http://example.com/myPhotos:BdayParty",
    "assigner": "http://example.com/user44",
    "assignee": {
      "@type": "PartyCollection",
      "source":  "http://example.com/user44/friends",
      "refinement": [{
        "leftOperand": "foaf:age",
        "operator": "gt",
        "rightOperand": { "@value": "17", "@type": "xsd:integer" }
      }]
    },
    "action": { "@id": "ex:view" }
  }]
}

2.6.1 Permission 클래스

Permission은 모든 refinements가 충족된 action이, 모든 constraints가 충족되고 모든 duties가 이행된 경우 Asset에 대해 수행될 수 있도록 허용합니다.

Permission 클래스는 Rule 클래스의 하위 클래스이며, Rule 클래스의 모든 속성을 상속하고 다음과 같은 추가 속성 의미론을 가집니다:

• Permission은 Asset 유형의 target 속성 값을 하나 가져야(MUST) 합니다. (다른 relation 하위 속성이 사용될 수(MAY) 있습니다.)
• Permission은 기능적 역할을 위해 Party 유형의 assigner 및/또는 assignee 속성 값을 없거나 하나 가질 수(MAY) 있습니다. (다른 function 하위 속성이 사용될 수(MAY) 있습니다.)
• Permission은 Duty 유형의 duty 속성 값을 없거나, 하나 또는 여러 개 가질 수(MAY) 있습니다.

참고: 위 속성 카디널리티는 규범적 ODRL 정보 모델을 반영합니다. 일부 경우에는 일부 속성의 반복 출현도 지원되지만(Policy Rule Composition 및 Compact Policy에 설명됨), 규범적 원자 Policy는 위 속성 카디널리티와 일관됩니다.

duty 속성은 이행되어야(MUST) 하는 합의된 의무를 표현합니다. 즉, duty 속성은 Permission과 Duty 사이의 사전 조건을 명시합니다. 자세한 내용은 Permission을 가진 Duty 섹션을 참조하십시오.

예제 사용 사례: assigner http://example.com/org:xyz의 Policy Offer는 target Asset http//example.com/game:9090에 대한 play action을 표현하며, permission은 2017년 말까지 유효합니다.

{
   "@context": "http://www.w3.org/ns/odrl.jsonld",
   "@type": "Offer",
   "uid": "http://example.com/policy:9090",
   "profile": "http://example.com/odrl:profile:07",
   "permission": [{
       "target": "http://example.com/game:9090",
       "assigner": "http://example.com/org:xyz",
       "action": "play",
       "constraint": [{
           "leftOperand": "dateTime",
           "operator": "lteq",
           "rightOperand": { "@value": "2017-12-31", "@type": "xsd:date" }
       }]
   }]
}

2.6.2 Prohibition 클래스

Prohibition은 모든 refinements가 충족된 action이, 모든 constraints가 충족된 경우 Asset에 대해 수행되는 것을 허용하지 않습니다. action이 수행되어 Prohibition이 위반된 경우, Prohibition의 상태를 위반되지 않음으로 설정하려면 모든 remedies가 MUST 이행되어야 합니다.

Prohibition 클래스는 Rule 클래스의 하위 클래스이며, Rule 클래스의 모든 속성을 상속하고 다음과 같은 추가 속성 의미론을 가집니다:

• Prohibition은 Asset 유형의 target 속성 값을 하나 가져야(MUST) 합니다. (다른 relation 하위 속성이 사용될 수(MAY) 있습니다.)
• Prohibition은 기능적 역할을 위해 Party 유형의 assigner 및/또는 assignee 속성 값을 없거나 하나 가질 수(MAY) 있습니다. (다른 function 하위 속성이 사용될 수(MAY) 있습니다.)
• Prohibition은 Duty 유형의 remedy 속성 값을 없거나, 하나 또는 여러 개 가질 수(MAY) 있습니다.

참고: 위 속성 카디널리티는 규범적 ODRL 정보 모델을 반영합니다. 일부 경우에는 일부 속성의 반복 출현도 지원되지만(Policy Rule Composition 및 Compact Policy에 설명됨), 규범적 원자 Policy는 위 속성 카디널리티와 일관됩니다.

remedy 속성(failure 속성의 하위 속성)은 Prohibition이 위반된 경우 이행되어야(MUST) 하는 합의된 의무를 표현합니다. 즉, remedy 속성은 Prohibition의 action이 수행된 경우 이행되어야 하는 Duty를 명시합니다. 자세한 내용은 Prohibition을 가진 Remedy 섹션을 참조하십시오.

예제 사용 사례: target Asset http://example.com/photoAlbum:55의 assigner는 Permission과 Prohibition을 모두 포함하는 Agreement Policy를 표현합니다. assigner Party http://example.com/MyPix:55는 assignee Party http://example.com/assignee:55에게 Permission display를 할당하는 동시에 target Asset을 archive하는 것을 Prohibition으로 설정합니다. 또한 Policy에 충돌(예: Permissions와 Prohibitions 사이)이 있는 경우, Policy의 conflict 속성은 perm으로 설정되어 Permissions가 우선함을 나타냅니다.

{
    "@context": "http://www.w3.org/ns/odrl.jsonld",
    "@type": "Agreement",
    "uid": "http://example.com/policy:5555",
    "profile": "http://example.com/odrl:profile:08",
    "conflict": "perm",
    "permission": [{
        "target": "http://example.com/photoAlbum:55",
        "action": "display",
        "assigner": "http://example.com/MyPix:55",
        "assignee": "http://example.com/assignee:55"
    }],
    "prohibition": [{
        "target": "http://example.com/photoAlbum:55",
        "action": "archive",
        "assigner": "http://example.com/MyPix:55",
        "assignee": "http://example.com/assignee:55"
    }]
}

2.6.3 Duty 클래스

Duty는 모든 refinements가 충족된 action을 수행해야 하는 의무입니다. 모든 constraints가 충족되고, 모든 refinements가 충족된 해당 action이 수행된 경우 Duty는 이행됩니다. 해당 action이 수행되지 않은 경우, Duty를 이행하려면 모든 consequence도 이행되어야 합니다. 즉, consequences는 함께 이행되어야 하는 추가 Duties입니다. (참고: duty 또는 obligation 속성이 참조하는 Duties만 consequence 속성을 사용할 수 있습니다.)

Duty 클래스는 Rule 클래스의 하위 클래스이며, Rule 클래스의 모든 속성을 상속하고 다음과 같은 추가 속성 의미론을 가집니다:

• Duty는 Duty가 직접 적용되는 주요 대상 Asset을 나타내기 위해 Asset 유형의 target 속성 값을 없거나 하나 가질 수(MAY) 있습니다. (다른 relation 하위 속성이 사용될 수(MAY) 있습니다.)
• Duty는 기능적 역할을 위해 Party 유형의 assigner 및/또는 assignee 속성 값을 없거나 하나 가질 수(MAY) 있습니다. (다른 function 하위 속성이 사용될 수(MAY) 있습니다.)
• Duty는 duty 또는 obligation 속성을 가진 Rule이 해당 Duty를 참조하는 경우에만 Duty 유형의 consequence 속성 값을 없거나, 하나 또는 여러 개 가질 수 (MAY) 있습니다.

참고: 위 속성 카디널리티는 규범적 ODRL 정보 모델을 반영합니다. 일부 경우에는 일부 속성의 반복 출현도 지원되지만(Policy Rule Composition 및 Compact Policy에 설명됨), 규범적 원자 Policy는 위 속성 카디널리티와 일관됩니다.

Duty 클래스에는 다음 추가 요구 사항도 있습니다:

• duty를 수행할 의무가 있는 Party는 Duty Action을 수행할 능력이 있어야(MUST) 합니다.
• duty를 수행할 의무가 있는 Party는 Duty를 충족해야(MUST) 합니다.

consequence 속성(failure 속성의 하위 속성)은 Permission에 대한 합의된 Policy obligation 또는 duty를 이행하지 않은 결과를 표현하는 데 사용됩니다. 이 중 하나라도 이행되지 않으면, consequence Duties도 또한 새로운 요구 사항이 되며, 이는 원래 obligation 또는 duty뿐 아니라 consequence Duties도 모두 MUST 이행되어야 함을 의미합니다.

consequence 속성은 Permission duty 또는 Policy obligation에 대한 consequence인 Duty에서 사용되어서는 안 됩니다(MUST NOT).

2.6.4 Policy를 가진 Obligation 속성

Policy는 Duty를 이행해야 하는 obligation을 포함할 수(MAY) 있습니다. 모든 constraints가 충족되고, 모든 refinements가 충족된 해당 action이 수행된 경우 obligation은 이행됩니다.

예제 사용 사례: 아래 Agreement는 assigner http://example.com/org:43에서 assignee http://example.com/person:44에게 EU500.00의 payment amount로 assigner를 보상해야 하는 obligation을 포함합니다.

{
  "@context": "http://www.w3.org/ns/odrl.jsonld",
  "@type": "Agreement",
  "uid": "http://example.com/policy:42",
  "profile": "http://example.com/odrl:profile:09",
  "obligation": [{
      "assigner": "http://example.com/org:43",
      "assignee": "http://example.com/person:44",
      "action": [{
          "rdf:value": {
            "@id": "odrl:compensate"
          },
          "refinement": [
            {
              "leftOperand": "payAmount",
              "operator": "eq",
              "rightOperand": { "@value": "500.00", "@type": "xsd:decimal" },
              "unit": "http://dbpedia.org/resource/Euro"
            }]
        }]
    }]
}

Policy는 obligation을 이행하지 않은 consequence도 포함할 수(MAY) 있습니다.

예제 사용 사례: 아래 Agreement는 assigner http://example.com/org:43에서 assignee http://example.com/person:44에게 target Asset을 삭제해야 하는 obligation을 포함합니다. obligation이 이행되지 않으면, consequence로 assigner는 이제 지명된 자선 단체에 EU10.00을 보상해야(MUST) 합니다(obligation Duty를 이행하는 것과 함께).

{
    "@context": "http://www.w3.org/ns/odrl.jsonld",
    "@type": "Agreement",
    "uid": "http://example.com/policy:42B",
    "profile": "http://example.com/odrl:profile:09",
    "assigner": "http://example.com/org:43",
    "assignee": "http://example.com/person:44",
    "obligation": [{
	   "action": "delete",
	   "target": "http://example.com/document:XZY",
	   "consequence": [{
	   	 "action": [{
	   	     "rdf:value": { "@id": "odrl:compensate" },
	   	     "refinement": [{
	   	        "leftOperand": "payAmount",
	   	        "operator": "eq",
	   	        "rightOperand": { "@value": "10.00", "@type": "xsd:decimal" },
	   	        "unit": "http://dbpedia.org/resource/Euro"
	   	     }]
	   	 }],
	   	 "compensatedParty": "http://wwf.org"
         }]
    }]
}

2.6.5 Permission을 가진 Duty 속성

Duty는 Permission에서 Duty로 이어지는 duty 속성 관계를 사용하여 이행을 요구하는 사전 조건으로 지정될 수(MAY) 있습니다.

Permission에 여러 Duties가 있는 경우, 모든 Duties는 이행되기로 합의되어야 (MUST) 합니다. 여러 Permissions가 동일한 Duty를 (uid 속성을 통해) 참조하는 경우, Duty는 한 번만 이행되면 됩니다.

Duty에 function 하위 속성이 선언되어 있지 않은 경우, 이러한 기능적 역할은 참조하는 Permission에 선언된 것과 동일합니다.

예제 사용 사례: Party http://example.com/assigner:sony는 target asset http://example.com/music/1999.mp3을 play하도록 Offer를 만듭니다. permission에는 payAmount가 $EU5.00인 refinement를 가진 compensate action에 대한 duty가 포함됩니다. duty에는 또한 event가 policyUsage보다 작다는 constraint가 있으며, 이는 permission rule이 수행되기 전에 duty rule(즉 보상)이 수행되어야 함을 의미합니다.

{
    "@context": "http://www.w3.org/ns/odrl.jsonld",
    "@type": "Offer",
    "uid": "http://example.com/policy:88",
    "profile": "http://example.com/odrl:profile:09",
    "permission": [{
        "assigner": "http://example.com/assigner:sony",
        "target": "http://example.com/music/1999.mp3",
        "action": "play",
        "duty": [{
           "action": [{
              "rdf:value": { "@id": "odrl:compensate" },
              "refinement": [{
                 "leftOperand": "payAmount",
                 "operator": "eq",
                 "rightOperand": { "@value": "5.00", "@type": "xsd:decimal" },
                 "unit": "http://dbpedia.org/resource/Euro"
              }]
            }],
            "constraint": [{
                "leftOperand": "event",
                "operator": "lt",
                "rightOperand": { "@id": "odrl:policyUsage" }
            }]
        }]
    }]
}  

2.6.6 Permission/Obligation Duty를 가진 Consequence 속성

Permission의 duty와 Policy의 obligation은 해당 duty 또는 obligation을 이행하지 않은 것에 대한 consequence Duty를 포함할 수(MAY) 있습니다. 이 경우, Permission/Obligation Duty의 최종 상태를 이행됨으로 설정하려면 모든 consequence Duties도 MUST 이행되어야 합니다.

consequence 속성은 failure 속성의 하위 속성입니다. consequence 속성에 대한 자세한 내용은 Duty 클래스 섹션을 참조하십시오.

예제 사용 사례: 아래 Agreement는 assigner http://example.com/org:99와 assignee http://example.com/person:88 사이에서, assignee가 Asset http://example.com/data:77을 배포할 수 있도록 허용하되 해당 asset을 Party http://australia.gov.au/에 귀속해야 한다는 사전 조건을 둡니다. assignee가 duty를 이행하지 않거나, duty를 이행하지 않고 asset을 배포하면, consequence로 http://example.com/dept:100에 의해 추적되는 것도 포함됩니다.

{
    "@context": "http://www.w3.org/ns/odrl.jsonld",
    "@type": "Agreement",
    "uid": "http://example.com/policy:66",
    "profile": "http://example.com/odrl:profile:09",
    "permission": [{
        "target": "http://example.com/data:77",
        "assigner": "http://example.com/org:99",
        "assignee": "http://example.com/person:88",
        "action": "distribute",
        "duty": [{
            "action": "attribute",
            "attributedParty": "http://australia.gov.au/",
            "consequence": [{
               "action": "acceptTracking",
               "trackingParty": "http://example.com/dept:100"
            }]
        }]
    }]
}

2.6.7 Prohibition을 가진 Remedy 속성

remedy 속성은 Prohibition이 수행되어 위반된 경우 이행되어야(MUST) 하는 합의된 Duty를 표현합니다. Prohibition action이 수행되면, Prohibition의 위반을 처리하고 그 상태를 위반되지 않음으로 설정하기 위해 모든 remedy Duties가 MUST 이행되어야 합니다. remedy 속성은 failure 속성의 하위 속성입니다.

remedy는 consequence Duty를 포함하는 Duty를 참조해서는 안 됩니다(MUST NOT).

예제 사용 사례: 아래 Agreement는 assigner http://example.com/person:88와 assignee http://example.com/org:99 사이에서, assignee가 Asset http://example.com/data:77을 index하는 것을 금지합니다. assignee가 실제로 target asset을 index하는 경우, remedy는 target asset http://example.com/data:77을 anonymize해야(MUST) 하는 것입니다.

{
    "@context": "http://www.w3.org/ns/odrl.jsonld",
    "@type": "Agreement",
    "uid": "http://example.com/policy:33CC",
    "profile": "http://example.com/odrl:profile:09",
    "prohibition": [{
        "target": "http://example.com/data:77",
        "assigner": "http://example.com/person:88",
        "assignee": "http://example.com/org:99",
        "action": "index",
        "remedy": [{
            "action": "anonymize",
            "target": "http://example.com/data:77"
        }]
    }]
}

2.7.1 Compact Policy

ODRL Policy는 Policy 수준에서 선언되고 모든 Rules에 공유되며 공통되는 속성을 보유할 수 (MAY) 있습니다. 이는 더 compact한 직렬화를 지원하기 위한 short-cut 방법만을 목적으로 합니다. 이러한 공유 속성은 Policy 수준 속성(Policy Class 섹션에 정의된 것과 같은)으로 해석되어서는 안 됩니다(MUST NOT).

공유될 수(MAY) 있는 속성(아래 그림에 표시됨)은 다음을 포함합니다:

• 하나 또는 여러 개의 action 속성.
• 하나 또는 여러 개의 relation 하위 속성(target 등).
• 하나 또는 여러 개의 function 하위 속성(assigner 및 assignee 등).

Policy에서 short-cuts를 확장하기 위한 ODRL 검증 요구 사항은 다음과 같습니다:

1. Policy의 각 Rule에 대해:
   • 관련된 모든 공유 속성(Policy 수준)을 검증합니다.
   • 이 속성들을 Rule에 복제합니다.
2. Policy 수준에서 선언된 공유 속성을 제거합니다

또한 Policy에서 atomic Rules를 만들기 위한 ODRL 검증 요구 사항(이전 섹션에서 정의됨)을 따릅니다.

compact ODRL Policies는 적합성 처리를 할 때 atomic Policies로 확장하는 것이 권장됩니다(RECOMMENDED).

아래 예제는 그러한 공유 공통 속성이 Policy에 적용된 모습을 보여 줍니다:

{
    "@context": "http://www.w3.org/ns/odrl.jsonld",
    "@type": "Policy",
    "uid": "http://example.com/policy:8888",
    "profile": "http://example.com/odrl:profile:21",
    "target": "http://example.com/music/1999.mp3",
    "assigner": "http://example.com/org/sony-music",
    "action": "play",
    "permission": [{
        "assignee": "http://example.com/people/billie"
        },
        {
        "assignee": "http://example.com/people/murphy"
        }]
}  

아래 예제는 위 ODRL 검증 요구 사항에 따라 이러한 공유 속성이 Policy의 Permissions로 확장되는 방식을 보여 줍니다.

{
    "@context": "http://www.w3.org/ns/odrl.jsonld",
    "@type": "Policy",
    "uid": "http://example.com/policy:8888",
    "profile": "http://example.com/odrl:profile:21",
    "permission": [{
        "assignee": "http://example.com/people/billie",
        "target": "http://example.com/music/1999.mp3",
        "assigner": "http://example.com/org/sony-music",
        "action": "play"
        },
        {
        "assignee": "http://example.com/people/murphy",
        "target": "http://example.com/music/1999.mp3",
        "assigner": "http://example.com/org/sony-music",
        "action": "play",
        }]
}