Giter Site home page Giter Site logo

odrl's Introduction

W3C ODRL Community Group

The ODRL Community Group supports the promotion and future development of the W3C ODRL recommendations:

Specifically, the ODRL CG will:

  • Promote ODRL V2.2 to existing and new sectors/industries
  • Nurture an ODRL implementors community
  • Publish reports related to ODRL usage
  • Support development of ODRL Profiles (and host for smaller communities)
  • Register ODRL Profiles
  • Collaborate with W3C on ODRL errata maintenance
  • Plan for future major enhancements to ODRL (V3.0)

Participate

See upcoming general meetings and sub-groups meetings, including meeting minutes, at the ODRL Community Group Wiki.

Subscribe to [email protected] to recieve reminder and meeting link.

Useful links


This repository is administered by Renato Iannella and Ivan Herman

odrl's People

Contributors

anmunoz avatar bact avatar benedictdd avatar benedictws avatar besteves4 avatar davidfichtmueller avatar dontcallmedom avatar fornaran avatar iherman avatar jenspiegsa avatar jsalvachua avatar nitmws avatar riannella avatar vroddon avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

odrl's Issues

Incorrect Usage of uid/@id in Implementation Best Practices

The best practices state that Example 1 (JSON-LD) and Example 2 (turtle) are equivalent. I am wondering if I might miss something but if I translate the JSON-LD, my output looks different mainly on the subject position and the odrl:uid property.

Example 1:

{
	 "@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"
	 }]
}

Which I would translate to (please note the blank node at the root and the strings at the object positions):

@prefix odrl:  <http://www.w3.org/ns/odrl/2/> .

_:b  a                odrl:Set ;
  odrl:permission  [ odrl:action  "use" ;
                     odrl:target  "http://example.com/asset:9898.movie"   ] ;
  odrl:uid         "http://example.com/policy:1010"
.

but the Example 2 actually says (with a few adjustments to differing URIs):

@prefix odrl:  <http://www.w3.org/ns/odrl/2/> .

<http://example.com/policy:1010> a odrl:Set ;     
  odrl:permission [
    odrl:target <http://example.com/asset:9898.movie> ;
    odrl:action odrl:use
  ] .

Which in my view outlines the following issues:

  • http://example.com/policy:1010 as the subject requires "@id": "http://example.com/policy:1010" instead of "uid": "http://example.com/policy:1010" in the JSON-LD.
  • <#> odrl:action odrl:use . in Turtle needs a JSON-LD representation like "action": {"@id": "use"}

As I personally think that the Turtle representation of Example 2 is the right way (whatever right means), this brings me to two questions:

  1. Why is odrl:uid mandatory? Isn't the intention rather to always have "@id" set in JSON-LD and thereby preventing blank nodes on the level of policies? If so, the constraint in the recommendation (section 2.1) needs to be formulated differently...
  2. Shouldn't the JSON-LD example not rather look like this, even though being more ugly on the JSON-LD-side?
{
	 "@context": "http://www.w3.org/ns/odrl.jsonld",
	 "@type": "Set",
	 "@id": "http://example.com/policy:1010",
	 "permission": [{
 		"target": { "@id": "http://example.com/asset:9898.movie" },
 		"action": { "@id": "use" }
	 }]
}

Appreciate your feedback!

Typo on ODRL Implementation Best Practices

Hi,

There is a typo in 4. Sample ODRL policies - Example 1

  odrl:permission
  [ 
     odrl:action odrl:distribute , odrl:modify , odrl:reproduce         **;      # <-** 
     odrl:duty
	 [   
	    odrl:action cc:Notice , cc:ShareAlike
	 ] ;
  ] ;

Regards

ODRL Best Practices document needs corrections and add-ons

These comments are based on the ODRL BP document version of 19 March 2018.
And I'm aware that the document is Under Construction and I point only at issues regarding the existing data, not at missing things (with an exception in 2 below).

  1. General: all examples using an action different from "use" or "transfer" must have a profile - but they don't have one
  2. Based on 1.: the use of profiles should be explained
    -- how to add one to many profile ids
    -- how to add one to many JSON-LD file links to @context
  3. General: the numbering of sections breaks below 3. - the following 1 should be 3.1 etc4. re section 1.2: the narrative talks about a photo, the asset id makes one think about a movie
  4. Example 1.2A shows https://www.wikidata.org/wiki/Q183 as id for Germany. But that's the URL of the Wikidata page providing information about this entity, the ID of Germany as Wikidata entity is https://www.wikidata.org/entity/Q183 - see "concept URI" on https://www.wikidata.org/wiki/Wikidata:Data_access
  5. Example 1.2A shows a "comment" property of constraint - but the odrl.jsonld does not map this property name to an id. This way "comment" is invalid.
  6. Examples 1.2B and 1.2C: to comply with the narrative the operator of the dateTime constraint should be gteq. (Currently the permitted display starts on 2 January 2019.)
  7. re "7 How to generalize action" - diagram: it shows "transfer" as narrower term of "use" - but they must be siblings at the top level.

It's ok for me to contribute to fixing these issues.

How to define terms of a profile in a machine-readable way?

While fine tuning the JSON-LD context for IPTC's RightsML (see https://iptc.org/std/RightsML/odrl-profile/rightsml.jsonld) I came across this issue:

  • An ODRL Policy in JSON-LD has to included the JSON-LD context defined by ODRL (http://www.w3.org/ns/odrl.jsonld)
  • This context includes all terms (Things) defined by the ODRL 2.2 Information Model ...
  • ... and also terms defined by the ODRL 2.2 Common Vocabulary (https://www.w3.org/TR/odrl-vocab/#vocab-common). These terms are NOT defined by the ODRL 2.2 Recommendation, therefore if the action "play" should be used in a permission an ODRL profile defining this term is required.
  • As a result a JSON-LD Policy using a profile must include the context of the profile AND the ODRL context.
  • This raises the essential question: what really "defines" which terms are valid in a Policy?
    ** If the action "play" is not adopted/defined by a profile it still can be found in the ODRL context. How can it be told: the action "play" should not be used with this Policy?
    ** A variant which can be used by humans is to refer to a document defining a profile in a human readable way. But as far as I know there is no machine readable variant available for ODRL.

A confusing detail: the ODRL context document includes many of the actions listed in the ODRL Common Vocabulary but not all ...

JSON-LD context incorrectly maps odrl:uid to @id

The JSON-LD context "https://www.w3.org/ns/odrl.jsonld" used in all examples (eg. 5) incorrectly maps what one would assume as being the odrl:uid property to JSON-LD's @id syntax keyword.

Screenshot 2022-11-10 at 19 03 43

Which results in the following:

  • example json-ld:
      {
         "@context": "http://www.w3.org/ns/odrl.jsonld",
         "@type": "Policy",
         "uid": "http://example.org/policy-x"
      }
    
  • corresponding rdf as turtle:
    prefix odrl: <http://www.w3.org/ns/odrl/2/>
    
    <http://example.org/policy-x> a odrl:Policy .
  • expected rdf as turtle:
    prefix odrl: <http://www.w3.org/ns/odrl/2/>
    
    []
        a odrl:Policy ;
        odrl:uid <http://example.org/policy-x> .

It would be good if the context was ammended to reflect the ODRL vocabulary. I would be happy to submit a PR.

See also: #26

Inconsistencies around prohibition, prohibition and obligation in a Policy

The definition of the Policy Class defines, among others:

A Policy MUST have at least one permission, prohibition, or obligation property values of type Rule

The ODRL Profile Mechanism defines, among others:

Additional Rule class: Create a subclass of the Rule class and define it as disjoint with all other Rule subclasses.

That does not fit:

  • The Policy Class specification lists 3 properties, all must be of type Rule, but the use of a specific subclass of Rules is not defined. The mentioned Permission, Prohibition and Obligation Class specifications don't defined details of what class must/should/can be used with one of these properties ...
  • ... but the ODRL Core Vocabulary is more precise: e.g. the term Has Permission, covering the property permission, defines as Range the Rule subclass Permission, semantically the same is defined for prohibition and obligation.
  • Profile ABC defines a subclass of Rule, the SuperProhibition
  • By these specifications it is NOT allowed to use this SuperProhibition as the three listed Policy Class properties must only be used with another specific Rule subclass - and it is not allowed to add new properties - at least I conclude this from the ODRL specs ...
  • ... and if defining and using a property superProhibition is allowed it is still mandatory to use one of permission/prohibition/obligation too.
  • Defining a subclass of Policy does not help profile ABC: as subclasses inherit properties (and their rules) the use of one out of permission/prohibition/obligation cannot be prevented ...
  • ... or can it? A formally tricky thing is that OWL does not support natively a cardinality of properties, this "at least one of permission/prohibition/obligation must be used" cannot be defined with OWL means. Do we assume that the free-text specifications of the ODRL Information Model provides the cardinality ...
  • ... but the free-text of the ODRL Information Model defines only that permission/prohibition/obligation must be used with a Rule class (or subclass) but not that permission must be an instance of the Permission class. This formally allows to use the property prohibition with the SuperProhibition class ...
  • ... so the ODRL Recommendation is running is circles between the free-text and the OWL specifications.

Conclusion: the ODRL Information Model has internal inconsistencies.

A typo error in section 2.6 Rule Class

In the section https://www.w3.org/TR/odrl-model/#rule

The sentence
Explicit sub-properties of the abstract relation, relation and failure properties must be used, the choice depending on the subclass of Rule in question.

Should have been
Explicit sub-properties of the abstract relation, function and failure properties must be used, the choice depending on the subclass of Rule in question.

W3C ODRL Use Case note

Antoine wrote:

The latest editor's draft of the Use Cases and Requirements at https://w3c.github.io/poe/ucr/ and dated 30 March 2018.
The latest official W3C working draft at https://www.w3.org/TR/poe-ucr/ is dated 23 February 2017 and is of course less up-to-date.
Is there any way that the community group could push the publication of the last editor's note to replace the old official working draft?

Hosting of mapped licenses

Nicolas Carr mentioned his interest in re-using our rdf licenses.
There are other mappings text-licenses->structured-licenses out there: those of (http://tldrlegal.com, non open), those in the Austrian project DALICC, those in France at INRIA, those at UPM in Madrid.
Most of these mappings are not right ODRL (or not ODRL at all).
Can we create a repo in the github with curated files? Main policies:

  • huge disclaimer: the mapping is authored by the author, not supported anyhow by the group
  • everybody can contribute with new mappings or modification of the existing (pull request in the github). unless there is a conflict, we approve requests
    We could get some support from the Australian party, and I think they want something neutral, like what I am suggesting. We can also get the support of the language resources community for this --I have been asked for that, actually....

Update the CG Home Page

Update Implementors/developers page with V2.2 info

Update Profiles page (order by version)

Remove the Draft CC Profile from the Reports list

Problem with the odrl.jsonld context file and CORS

If you run:

curl -I -H "origin: https://test.example" https://www.w3.org/ns/odrl.jsonld

The server will rewrite the access-control-allow-origin header to use the passed origin value and tell the client to cache it for 21600 seconds. This means that the same browser trying to hit that URL over CORS from any other site will use the cached value and fail. The remedy is for the server to stop using the sent origin value and just use * ... or to include a vary: origin header so the client knows to use a different cached value based on the origin value sent in the request. Either fix should address the problem.

Create asset Action not present in ODRL

In an usage control enforcement project, I am trying to use ODRL as a language as policy language for CRUD decisions.

To the best of my knowledge, it is not possible to state with an ODRL Rule to declare an odrl:Action that an entity is allowed to create an asset.

In an issue on the aforementioned project, I argue that it is possible however to use odrl:use for this purpose.
The problem with odrl:use, however, is that it allows for way more than just creating an asset.

My question thus is, shouldn't it be possible to state with ODRL that an entity is allowed to create an asset? (e.g. by using an action such as odrl:create with as description "The act of creating an Asset")

A typo error in Example Use Case of EXAMPLE 21

In the Example Use Case of EXAMPLE 21 stated in section https://www.w3.org/TR/odrl-model/#duty

The phrase
.... then a consequence is that the assigner MUST now also compensate ...

Must be changed to
.... then a consequence is that the assignee MUST now also compensate ...

Context

The Duty class also has these additional requirements:

The Party obligated to perform the duty MUST have the ability to exercise the Duty Action.
The Party obligated to perform the duty MUST satisfy the Duty.

Semantics for overlapping Permissions

Hi

Permission 1 grants use of all apps on my iPhone.

Permission 2 grants use of the WhatsApp app, but has the duty to gain consent first.

These two permissions seem to overlap, and if I wanted to use WhatsApp application Permission 2 is intuitively the more specialised permission to use. However, a computer could find Permission 1 and side step the duty to gain consent.

It could be argued the permissions are poorly modelled, in which case what would be the best way to assign a duty to a very specialised subset?

Any opinions on this?

Thanks,
James.

ODRL Temporal Profile TIME modelling is invalid + other suggestions

In the ODRL Temporal Profile, some of the use of OWL-TIME is invalid. Example 1:

[] a tpl:TemporalAgreement ;
    tpl:version  :T1-V1 , :T1-V2 . 


:T1-V1  a  odrl:Agreement ;
    tpl:effectiveDate [
        a time:ProperInterval ;
        time:before   "2020-01-01T00:00:00Z"^^xsd:dateTime
    ] ;
    tpl:temporalPermission :P1 . 
               

:T1-V2  a odrl:Agreement ;
    tpl:effectiveDate [
        a time:ProperInterval ;
        time:after   "2020-01-01T00:00:00Z"^^xsd:dateTime
    ] ;
   tpl:temporalPermission :P1 , :P2 .

time:before & time:after are OWL Object Properties with range values of time:TemporalEntity, so triples like :T1-V1 time:before "2020-01-01T00:00:00Z"^^xsd:dateTime in the above won't work since the property is indicating a Datatype object. Also, a dateTimeStamp is used (includes 'Z') but dateTime but it should actually just be a date since no time value is given.

I think what is meant is:

    tpl:effectiveDate [
        a time:ProperInterval ;
        time:hasStart [
               a time:Instant ;
               time:inXSDDate "2020-01-01"^^xsd:dateTime ;
        ] ;
    ] ;

So here the pProperInterval indicated by the effectiveDate has a starting Instant whose XSD representation is given. Of course, in practice, you could just do this:

    tpl:effectiveDate [
        time:hasStart [
               time:inXSDDate "2020-01-01"^^xsd:dateTime ;
        ] ;
    ] ;

Remove class indicators.

Suggestions

Looking over the example though, I suggest renaming effectiveDate to effectivePeriod or effectiveInterval since the property is indicating a ProperInterval not a date of any sort.

Also, why do you need a TemporalObject class? This is just mirroring TIME's time:TemporalEntity but not adding any value (no distinguishing properties) and since you are making greate use of TIME, you should just directly use TemporalEntity.

I'm not even sure if you need TemporalPolicy since this could just be a standard odrl:Policy with a time:hasTime property indicating that it is temporal in nature.

Taking this to the extreme, you might even get rid of effectiveDate and just use time:hasTime or, at the very least, make effectiveDate (after renaming to effectiveInterval, effectivePeriod etc.) a subPropertyOf time:hasTime.

Guidelines for what a Policy or a Rule subclass may define

Currently I'm working on the Profile Best Practices document.

The ODRL 2.2 Recommendation allows in its Profile Mechanism to define subclasses of Policy of of Rule for a Profile.
But unfortunately the rules or guidelines how to subclass these two classes are vague:

  • Policy: An ODRL Policy MAY be subclassed to more precisely describe the context of use of the Policy that MAY include additional constraints that ODRL processors MUST understand.
  • Rule: nothing

This may let makers of a Profile conclude that anything not violating the rules of OWL classes, RDFS Subclasses and of these "outlines" above can be done.
It would be great to give a clearer guidelines in the Best Practices document.

Please have a look at the sections "Defining a subclass of Policy allows:" and "Defining a subclass of Rule allows:" if this covers your understanding of how to define such subclasses.

Discovery of an ODRL resource

Use case: agent wants to know how to display or further process policies directly associated with a resource.

If the ODRL policies are managed separately from the resources it describes, there needs to be a way to discover the policies.

What is the discovery path for agents starting with a resource that wants to find out about the ODRL resource (including information on policies, rules, actions, permissions, prohibitions, duties, assets, parties, constraints).

Is there an intended ODRL "protocol"? Is it in this CG scope?

By protocol, I mean something very lightweight eg:

HEAD /foo

200
Link: <https://example.org/foo.odrl>; rel="odrl"

(or along the lines of Link: <https://example.org/foo.odrl>; rel="http://www.w3.org/ns/odrl/2/rights">)

Certainly ODRL information can be discovered on the data layer (using whatever most appropriate property):

<https://example.org/foo>
   <http://purl.org/dc/terms/rights> <https://example.org/foo.odrl> .

but I'm primarily interested in the discovery of a resource that may hold all ODRL information about the associated resource. When the general use case is taken in context of authorization, discovery through the HTTP header would allow the consumer to get further details about the target.

Keep meeting notes in the repository

Hi.
To avoid issues in the meeting notes (as I mention here), I suggest we create a folder in this repository to keep one file with notes per meeting we have, and not send it through the mailing list.
That way, if anything needs to be corrected we can easily do it and we can also review last month's meeting notes as the first topic in each meeting to ensure that everyone is ok with what is recorded there.

Expressing preferred policies or templates

Use case:

User wants to check whether the storage's policies are compatible with their own preferred policies. If there are any discrepancies, the user should be warned and given a chance to make a decision about available options.

Does ODRL provide a solution that meets the requirements of this use case?

An implementation:

The brief screencast in solid/specification#355 (comment) demonstrates an application that is aware of the storage's offer with a possible permission of action to sell assets stored in that location and selling happens to be a prohibited action by the user. The application brings the discrepancy to user's attention.

Below example policies are used by the storage (offer/permission) and the user's profile document (agreement/prohibition). I understand that the modeling of the preferred policy may be wrong or not even possible. Hence, I'd like to know if this can be accomplished with the current state of ODRL Information Model and/or possible minor extensions to express "preference" (or a template of sorts). If the expression of preference should be claimed in an external namespace, that's completely fine. Just looking for guidance.

Example (snippet) storage's policy:

</>
  odrl:hasPolicy <#policy> .

<#policy>
  a odrl:Policy, odrl:Offer ;
  odrl:permission :permission ;
  odrl:target <https://example.org/> .

:permission
  a odrl:Permission ;
  odrl:action odrl:sell ;
  odrl:assigner <https://example.org/profile#storage-org> .

Example (snippet) user's policy:

<https://csarven.ca/#i>
  solid:preferredPolicy :preferred-policy .

:preferred-policy
  a odrl:Policy, odrl:Agreement ;
  odrl:prohibition :preferred-policy-prohibition .

:preferred-policy-prohibition
  a odrl:Prohibition ;
  odrl:action odrl:sell ;
  odrl:assigner <https://csarven.ca/#i> .
  odrl:assignee foaf:Agent ;

For the time being, there is not much to the semantics of solid:preferredPolicy beyond simply referring to a "preferred policy" (i.e., an odrl:Policy) - again, it was only to exemplify the need. Perhaps odrl:hasPolicy could've been re-used, I don't know.

Connect `odrl:Agreement` with an `odrl:Offer` and an `odrl:Request` that originated the agreement

Hi.

Are there any guidelines or recommended vocabulary terms (from ODRL or from other vocabs) to connect an odrl:Agreement with other policies?

The use-case I have in mind is the following:
A party publishes an odrl:Offer policy for the target data http://example.com/asset:1 and a second party makes an odrl:Request to that asset. The parties reach an agreement which is recorded using an odrl:Agreement. What properties (represented in the example below with <has offer> and <has request>) should be used to connect the agreement with the offer and the request that originated it?

:offer a odrl:Offer .
:request a odrl:Request .
:agreement a odrl:Agreement ;
        <has offer> :offer ;
        <has request> :request .

Use Cases for Best Practices guide?

Hi (with specific attn to @vroddon and @nitmws )
A while ago I was a contributor to two use cases, one on Europeana/DPLA and one on data quality policies, both using ODRL:
https://www.w3.org/community/odrl/wiki/Europeana/DPLA_In_Copyright_-_Educational_Use_Only (https://w3c.github.io/poe/ucr/#POE.UC.27)
https://www.w3.org/community/odrl/wiki/W3C_Data_on_the_Web_Best_Practices_-_Data_Quality_Policy (https://w3c.github.io/poe/ucr/#POE.UC.26)
At this time, they might require a refresh, but first I would like to know: would either (or both) of them be relevant for the ongoing work on Best Practices https://w3c.github.io/odrl/bp/ ?

Objects requiring licenses or constraining effective licenses?

After having compared ODRL to the "License Document Interchange Format (LDIF)" Rights Expression Language that I created, and patented, and in the late 1980's and early 1990's as part of the "Digital Distributed Licensing Architecture," I can see that ODRL, with an appropriate profile, would probably be able to express many of the same licenses that I designed LDIF to express. However, an important feature of LDIF seems to be missing, and I'm wondering if I simply haven't read the specs correctly or if I've missed one.

LDIF not only provides an ASN.1-based, machine-readable Rights Expression Language to describe licenses, it also provides language to be used by a licensed object to state requirements for those licenses which might authorize the object's use. For instance, in my patents, I describe how a digital object, or a tool displaying the object, could require the presence of a license having specific elements. My patents offer the example of a copy of Digital's "Amazing Graphic System" whose use is authorized if the user's licenses include at least one license from the set of:

"All Product Use Authorizations issued by Digital for the Product 'Amazing Graphics System' which contains a calling authorization for Digital's 'Amazing Database' Product." [The LDIF expression can be seen in Figure 46 of any of the patents listed below.]

What this means is that a license for some specific use of the "Amazing Graphics System" is insufficient unless it also contains a "Calling Authorization" (permission to invoke as a component) for the "Amazing Database" as a means for storing graphical objects. I assumed that there might be alternative methods for storing objects (e.g. simple files on disk, etc.) whose use might be authorized with different licenses or might not require an explicit license. Also, I was trying to deal with the problem of something like a Calling Authorization only being allowed when the calls were made by "Amazing Graphics System" and not when made from user-written or other products. (i.e. Authorization of use by one caller neither required nor implied authorization of calling by others.)

LDIF filters would also be useful for enabling a BookReader application to determine if it was authorized to display, or otherwise process, a specific digital version of Shakespeare's "Macbeth." The copy of "Macbeth" might have an embedded filter that required either a license for just that one book or for "Any works by Shakespeare" provided by the same publisher. In the absence of a specification embedded within the copy of Macbeth, a license allowing "Any work by Shakespeare" would have to include a listing of all such works, including Macbeth, and would be of limited utility if the set of "all works" had grown to include Macbeth after the license was initially issued. Another example, perhaps a better one, of the "growing set" problem, would be a copy of a weekly magazine that could be purchased either in isolation or as part of "all issues published in the year."

Does ODRL provide a means for an object, whose use is subject to licensing, to state that a license is expected and/or to define the set of licenses which are effective? If not, is this something that could be reasonably added via a Profile?

Note: The now long-expired DDSLA patents contain more detail on the LDIF Rights Expression Language, etc. They were: 5,745,879: Method and system for managing execution of licensed programs, 5,438,508: License document interchange format for license management system, 5,260,999: https://patents.google.com/patent/US5260999, and 5,204,897: Management interface for license management system.

Refine refinements

In section 2.5, the diagram:

image

The relationship "refinement" from [Party Collection | Asset Collection | Action ] implies a bounded relationship between the target/assignee/action and the constraint/logical constraint.

Since applying the Constraint is inherent to the Rule defining/using it (only applicable in the context of the Rule?), the relationship between the source/action, Rule, and the Constraint should (for clarity) be separated.

I propose that a better illustration of the relationship is (illustrating with the party collection):

Rule -----> [Refinement] ---> [ Party Collection ]
                                   |-----------> [ Constraint ]]
                                   |                ^      ^
                                   |                |      |   
                                   └-----------> [ Logical Constraint ]]

(IMHO, would recommend to create more examples with explicit naming references to nodes, having only implicit names and unravelled definitions might mislead the reader).

REQUEST for preliminary review: Verifiable Credentials Data Model 1.0

The Verifiable Claims Working Group's one standards-track specification, "Verifiable Credentials Data Model 1.0", is beyond First Public Working Draft but not yet ready for Candidate Recommendation.

Since you were the group that did the Permissions and Obligations Expressions work, we would like to ask for any early comments you might have on our admittedly incomplete specification, in an attempt to address any major issues earlier rather than later.

Would your group (or some members of your group) be willing to give the document an informal read-through? We are looking for comments within approximately a 60-day timeframe if possible.

The best place for comments is directly in our GitHub repo [1] as new issues, but comments sent to our comments mailing list [2] work as well. Comments on either the (stable) dated draft [3] or the live Editor's Draft [4] are fine, whichever is easiest for you.

If you need anything else from us first, please don't hesitate to contact the chairs directly.

Thank you,

Dan Burnett and Matt Stone, Co-chairs, Verifiable Claims Working Group

CC: Specification editors

[1] GitHub repo: https://github.com/w3c/vc-data-model
[2] Mailing list: [email protected]
[3] Most recent dated (fixed) draft: https://w3c.github.io/vc-data-model/WD/2018-07-18/
[4] Tip of tree editor's draft: https://w3c.github.io/vc-data-model/

Usage of `odrl:eq` and `odrl:isA` operators and missing operator for subclasses

Hi.

I have some questions regarding the use of the odrl:eq and the odrl:isA operators.
Currently, if we want to use a constraint such as the odrl:purpose with a string as a right operand (as in the example below) I guess we should use the odrl:eq operator.

ex:constraint a odrl:Constraint ;
        odrl:leftOperand odrl:purpose ;
        odrl:operator odrl:eq ;
        odrl:rightOperand "Research and Development" .

However, if we wish to use a hierarchical taxonomy such as the DPV’s taxonomy of purposes, we start to run into some problems. Constraining a purpose with the "equal" operator has issues -- what if the purpose is an instance - then we could use the "is A" operator I guess. But what if the purpose is a subclass or an instance of a subclass? What if we want the instances and the subclasses?

ex:constraint a odrl:Constraint ;
        odrl:leftOperand odrl:purpose ;
        odrl:operator odrl:isA ;
        odrl:rightOperand dpv:ResearchAndDevelopment .

There should be some consideration on whether ODRL should provide a "subclass" operator and what to do when people want to use more than one operator together, e.g., a purpose constraint for dpv:ResearchAndDevelopment including all its instances and subclasses.
More guidance on this topic should also be provided in the Best Practices document.

Diffference between Distribute and GrantUse

Hi

Not clear to me what the difference between these two terms is.

GrantUse:
definition: "To grant the use of the Asset to third parties"
note: "This action enables the assignee to create policies for the use of the Asset for third parties. The nextPolicy is recommended to be agreed with the third party. Use of temporal constraints is recommended."

Distribution:
definition: "To supply the Asset to third-parties."
note: "It is recommended to use nextPolicy to express the allowable usages by third-parties."

The distinction seems very subtle and open to interpretation, and I'm not sure I will necessarily get it right.

Any advice appreciated.
Thanks.

Add negation operator

Hi!

There is a not equal (odrl:neq) operator to express "that a given value is not equal to the right operand of the Constraint".

A similar negation operator could be useful for other operators such as having a "is Not A" operator to indicate that a given left operand is not an instance of the right operand of the Constraint. The same exercise can be done for other operators, e.g. odrl:isPartOf -> have a isNotPartOf

To not explode the number of operators, the creation of a "not" operator to be used together with the existent ones, e.g., using the existent odrl:isA with a new odrl:not, could also be considered.

Publication of ODRL Profiles

  1. Publication of profiles
    There should be an ODRL landing page for the profiles, an index. Apart from those in this namespace (https://w3c.github.io/odrl/profile-bigdata/), there may be other external --at least we have produced two.

If we want to have them as drafts in URIs such as https://w3c.github.io/odrl/profile-language/, I guess we should discuss them in the general call. Am I wrong? We are interested in the Language Resources case, not so much for the Access Control in Solid --other platforms such as the European Language Grid, Metashare and some Clarin nodes may use them in the next few monts, and they would rather have a more neutral space. I am now in Athens working on this actually...

ODRL Community Vocabulary

  • A community-supplied set of general terms
  • Have a few items to add to the vocab to kick-start the draft (see past discussions)
  • What will be the namespace?
  • Use the same ttl or different files ?
  • Process to follow ?
  • Who will be the Editors?
  • Auto-generate from a ttl file ?

Feedback on 'ODRL V2.2 Profile Best Practices'

Just a few typos:

  • seqence in the last sentence of 4.
  • uniqe in the title of 6.1

More personal opinions:

  • As someone interested into definining a new Constraint, I did not find a description in 4.x What an ODRL Profile can define
  • In 4.9, maybe there is a better way to handle the paragraph: It is not required to create a new subclass of Policy for this purpose… instead of the repetition several times.
  • In 4.10 Example 10 I found that the use case of the example not completely clear.

Creating Rule subclasses being a Permission, Prohibition or Duty

The discussion about issue #8 raised suggestions like:

  • A new Profile can define a new subclass of Rule and a new subclass of Policy with a property having the new Rule subclass as type
  • The constraint on the type of the Policy properties permission, prohibition and obligation should be lifted to allow more than a specific subclass of Rule as type.

On the other hand it was said the basic design of ODRL is to express only rules of kind permission, prohibition or obligation/duty, this should not be spoiled by opening up Policies to any - even awkward - kind of rule.

A suggestion how a) the design can be protected and b) opening up permission, prohibition and obligation to more than one specific subclass of Rule as type.

  • Create new subclasses of Rule: SuperPermission, SuperProhibition, SuperDuty
  • These classes inherit the Rule class as it is, nothing is omitted, nothing is added ...
  • ... but each one has clear semantics of what kind of Rule it covers.
  • The existing class Permission is made a subclass of SuperPermission, class Prohibition a subclass of SuperProhibition, Duty a subclass of SuperDuty.
  • The type (Range) of these Policy properties is changed: permission rdf:type SuperPermission, prohibition rdf:type SuperProhibition, obligation rdf:type SuperDuty . (This permits to use an instance of Permission with permission, but no other property. The same for Prohibition and Duty.)
  • The rules / best practice of a Profile is changed: only subclasses of SuperPermission, SuperProhibition or SuperDuty may be defined. As best practice: a subclass of SuperPermission means it can be used only with the property permission ... etc.

Changes to the Recommendation to fix this POE Erratum:

  • Only changes to the ODRL Vocabulary
  • Add 3 subclasses of Rule: SuperPermission, SuperProhibition, SuperDuty. Apply a skos:definition describing the characteristics of each of them.
  • Make Permission a subclass of SuperPermission, Prohibition as subclass of SuperProhibition, Duty a subclass of SuperDuty
  • Change the type/Range of permission, prohibition and obligation to the corresponding Super.... classes.

Compatibility considerations:

  • Using an instance of Permission with permission. of Prohibition with prohibition, of Duty with obligation is fully backward compatible. No properties are removed, no processing rules are changed.
  • Processing with RDF processor needs to be able to deal with two subclassing actions from Rule to Permission, Prohibition and Duty.
  • Automated generation of programming code from the OWL document may require an additional step, but no properties of the created classes are different from the current state.

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.