RE: odrl-ISSUE-12: Make asserting flexible values more flexible [ODRL Version 2.0 XML Encoding (Public) ]

(forwarding to list from Michael)

Renato,

you write "... payments can be expressed by assets." - what are the
alternatives to using assets?

Coming back to my initial proposal: we think of something like this below
for expressing that a minimum fee of 150 USD must be paid for the asset:

<o:duty>
	<o:action name="ov:pay"/>
	<o:constraint name="ov:paymentvalue" operator="ov:gteq"
rightOperand="150.00" rOpDatatype="xs:decimal" rOpUnits="iso4217a:USD" />
</o:duty>

New are:
- the constraint name "paymentvalue"
- the attribute rOpDatatype: it defines the datatype of the @rightOperand
value by using one of the XML Schema 1.0 data types
- the attribute rOpUnits: it defines the units which are applied to the
value of @rightOperand using a QName/QCode.

To add a very close use case: setting the date of a payment (which does not
require units):
<o:constraint name="ov:paymentduedate" operator="ov:lteq"
rightOperand="2012-07-31" rOpDatatype="xs:date" />

This combination of a value, its data type and its units is shown in many
examples in the RDF area for payments and other facets of an asset which can
be measured (weight, size etc.) - so we feel we don't propose something
completely new.

Best,
Michael


> -----Original Message-----
> From: Renato Iannella [mailto:ri@semanticidentity.com]
> Sent: Sunday, July 01, 2012 7:33 AM
> To: ODRL Community Group
> Subject: Re: odrl-ISSUE-12: Make asserting flexible values more flexible
> [ODRL Version 2.0 XML Encoding (Public) ]
> 
> 
> On 21 Jun 2012, at 06:07, ODRL Community Group Issue Tracker wrote:
> 
>> As the example 4.6 of the XML Encoding page of the ODRL specs
> (http://www.w3.org/community/odrl/two/xml/) shows the concrete value
> of a license fee has to be expressed as Asset.
>> As licensing fees a) are flexible and b) a very large amount of them
exist
> IPTC members raised the business requirement to have a more flexible way
> for expressing such literal values in ODRL.
>> We could think about adding attributes like @valuetype, @value and
> @valueunit to the asset element and to define some indicator (e.g. a
special
> @relation value) for this use case.
> 
> Hi michael - we purposely did not define any semantics/structure for
> payments (as we felt this would be domain specific) so instead we simply
> said that a payment can be expressed as an Asset.
> 
> The examples show assets from the UBL schema, but more complex
> payments (and terms) can be expressed using Good Relations [1].
> 
> Can you give an example of the additional attributes you mention and what
> they would represent?
> 
> Cheers...
> Renato Iannella
> Semantic Identity
> http://semanticidentity.com
> Mobile: +61 4 1313 2206
> 
> [1]
> http://www.heppnetz.de/ontologies/goodrelations/v1#PriceSpecification

Received on Thursday, 5 July 2012 05:22:08 UTC