RE: ODRL: SHACL requirements - draft

Re uid: ok, better to have a property which can be skipped than having forgotten a property ;-)

 

Re closed shapes: yes, it should be open for properties of other namespaces, but is there a chance to throw an error if an odr:assigner property is used in the Action Class?

 

Best,

Michael

 

From: Simon Steyskal [mailto:simon.steyskal@wu.ac.at] 
Sent: Saturday, September 2, 2017 8:27 AM
To: Michael Steidl (IPTC) <mdirector@iptc.org>; vrodriguez@fi.upm.es
Cc: W3C POE WG <public-poe-wg@w3.org>
Subject: RE: ODRL: SHACL requirements - draft

 

there's no uid property in rdf, that's a legacy concept of odrls xml serialization..

 

you could use closed shapes to require that certain nodes can only use specific properties, but there's absolutely no reason to have that in odrl as it would basically render profiles useless.

 

simon

 

 

 

-------- Original message --------

From: "Michael Steidl (IPTC)" <mdirector@iptc.org <mailto:mdirector@iptc.org> > 

Date: 9/2/17 08:04 (GMT+01:00) 

To: vrodriguez@fi.upm.es <mailto:vrodriguez@fi.upm.es>  

Cc: 'Simon Steyskal' <simon.steyskal@wu.ac.at <mailto:simon.steyskal@wu.ac.at> > 

Subject: RE: ODRL: SHACL requirements - draft 

 

Hi Victor,
sorry, but I disagree that checking the occurrence of a property like e.g. uid is not necessary: the IM defines how often it can occur and this needs to be checked by SHACL plus if the property holds an IRI value - or e.g. a date.

Simon, a question to you: 
does SHACL also cover the occurrence of unknow/not-defined properties?
Example: for the X Class only the properties odrl:uid and odrl:action are defined. SHACL checks an instance of X Class and finds the properties odrl:nonsense or mynamespace:ziplahuck in it. Does that raise an error?

Best,
Michael

-----Original Message-----
From: vrodriguez@fi.upm.es <mailto:vrodriguez@fi.upm.es>  [mailto:vrodriguez@fi.upm.es] 
Sent: Saturday, September 2, 2017 5:27 AM
To: Michael Steidl (IPTC) <mdirector@iptc.org <mailto:mdirector@iptc.org> >
Cc: 'Simon Steyskal' <simon.steyskal@wu.ac.at <mailto:simon.steyskal@wu.ac.at> >
Subject: Re: ODRL: SHACL requirements - draft

Yes, they have to be discussed.
I don't think they are necessary.
See you on Monday!
Víctor

"Michael Steidl (IPTC)" <mdirector@iptc.org <mailto:mdirector@iptc.org> > escribió:

> Hi Victor,
> thanks
> ... and I've added some missing properties ...
> Best
> Michael
>
> -----Original Message-----
> From: vrodriguez@fi.upm.es <mailto:vrodriguez@fi.upm.es>  [mailto:vrodriguez@fi.upm.es]
> Sent: Friday, September 1, 2017 8:48 PM
> To: Michael Steidl (IPTC) <mdirector@iptc.org <mailto:mdirector@iptc.org> >
> Cc: 'Simon Steyskal' <simon.steyskal@wu.ac.at <mailto:simon.steyskal@wu.ac.at> >
> Subject: Re: ODRL: SHACL requirements - draft
>
> Michael, Simon,
>
> I have done my job.
>
> Víctor
>
>
> "Michael Steidl (IPTC)" <mdirector@iptc.org <mailto:mdirector@iptc.org> > escribió:
>
>> Hi Simon and Victor,
>>
>>
>>
>> I’ve set up a Google sheet for writing down the IM requirements which 
>> should be 
>>
>> As this sheet can be edited by anybody having this URL I share it 
>> only with you.
>>
>>
>>
>> This is NOT a final version, just a first round of going over 
>> Constraint and Rule classes. But I would like to check if the 
>> information level is ok.
>>
>>
>>
>> Simon: does this look usable? What other information do you need?
>>
>> If you show me green light I will browse the classes again for details.
>>
>>
>>
>> Going over the specifications of these classes I noticed that the 
>> occurrence of property has an impact on the evaluation but I see no 
>> direct impact on what is required to make a class well-formed. E.g. 
>> if a Prohibition has an exercised action it must be checked for 
>> existing remedies, but they MAY be there = cardinality (0..unbounded).
>>
>> The only impact on cardinality I see is the cardinality of the 
>> consequence property, it depends on which property uses this Duty.
>>
>> Simon mentioned we said Duties must not be nested – how to express 
>> that by SHACL. But exactly that nesting is limited by this 
>> conditioned cardinality.
>>
>>
>>
>> Victor: feel free to add the data of the classes you cover to this 
>> Google sheet.
>>
>>
>>
>> Best,
>>
>> Michael