RE: Profile(s)?

It makes sense to me that a given provider would want to be able to issue a license that drew from multiple profiles. However, in this case, it is effectively a “super profile”, isn’t it?

Let’s pretend that there are profiles for each of the four media types that Alapan mentions: games, movies, music and books. And let’s further pretend that each of these has their own URL:

http://profile.example.org/games

http://profile.example.org/movies

http://profile.example.org/music

http://profile.example.org/books


In practice, as a recipient, I need to able to handle the superset of those profiles, if I’m going to be able to handle licenses. And, as Alapan points out, any conflicts between – say – games and movies needs to be sorted out by the provider when they assemble the super profile. So, I think that there could still be one profile URL (maybe http://profile.example.org/games+movies+music+books) but I think that – in practice – this one URL would list the combined profile that the recipient of the license needs to work with.

So, in summary, my view is that a provider needs to assemble a list of ODRL profiles into a single super profile anyway. So, only allowing a single profile URL in the ODRL (XML, JSON, RDF…) seems an OK restriction to me.

Regards,

Stuart




From: Alapan [mailto:alapan@gmail.com]
Sent: Wednesday, July 02, 2014 2:32 AM
To: Renato Iannella
Cc: ODRL Community Group
Subject: Re: Profile(s)?

An example from my perspective on why multiple profiles may be useful.

Say, you run an electronic multimedia store - games, movies, music, books etc. mtiple profiles would allow for different business models tailored for individual type of media - e.g. Books may be on a rental model while music may be on a purchase forever model. However, you may also wish to bundle media for special deals - e.g. A bundle with a movie, thesoundtrack, the novel which the movie is based in and the game based on the movie. Multiple profiles would allow or the expression of a single license covering all the profiles.

The challenge is on conflicts; if book profile only allows for rental and music profile only allows for purchase, how is this resolved?

I think multiple profiles should be allowed and conflict resolution should be an implementation decision.

Alapan

On Wednesday, July 2, 2014, Alapan <alapan@gmail.com<mailto:alapan@gmail.com>> wrote:
ODRL 1 allowed for multiple profiles, I assume it really would depend on deployment.

On Wednesday, July 2, 2014, Renato Iannella <ri@semanticidentity.com<javascript:_e(%7B%7D,'cvml','ri@semanticidentity.com');>> wrote:

On 26 Jun 2014, at 04:03, Michael Steidl (IPTC) <mdirector@iptc.org<mailto:mdirector@iptc.org>> wrote:


The 2.1 Date Model - http://www.w3.org/community/odrl/work/2-0-core-model-constraint-draft-changes/

says in 2.1.2 about Profile “ …. If multiple ODRL Profiles are used, then all the rules from each Profile MUST apply to the policy expression.”
This drives the assumption that multiple Profiles may be applied to a single policy.
But in XML the @profile attribute may only appear once and it takes only a single value. (Also the first sentence of 2.1.2 leans towards “there is only one identifier”)

This needs a decision: one or more profile(s)

Does anyone have any strong positions?

For greatest "flexibility" we started without any restrictions - allowing any number of profiles to be applied.
In reality, it would be just one profile (if any) being used.

(We can fix the XML with a space separated list of URIs, if required)

Cheers...
Renato Iannella
Semantic Identity
http://semanticidentity.com

Mobile: +61 4 1313 2206



--
Blog: http://idiots-mind.blogspot.com/

-------------------------------------------------------------
Life's a gamble - take a chance


--
Blog: http://idiots-mind.blogspot.com/

-------------------------------------------------------------
Life's a gamble - take a chance


The information contained in this communication is intended for the use
of the designated recipients named above. If the reader of this 
communication is not the intended recipient, you are hereby notified
that you have received this communication in error, and that any review,
dissemination, distribution or copying of this communication is strictly
prohibited. If you have received this communication in error, please 
notify The Associated Press immediately by telephone at +1-212-621-1898 
and delete this email. Thank you.
[IP_US_DISC]

msk dccc60c6d2c3a6438f0cf467d9a4938