RE: odrl-ISSUE-18: Single URI Namespace (Raising as an Issue)

As I'm the guy who raised an Issue (http://www.w3.org/community/odrl/track/issues/15) about how to indicate the use of a profile:

The current ODRL Data Model spec defines these features of a Profile:

    Document any additions to the Core Model
    Document any aspects of the Core Model that will have different default values
    Document which aspects of the Core Model are not being used (deprecated)
    Document Vocabulary terms
    Declare your communities namespace (see Encoding specifications)
    Share the Community profile with the ODRL community for feedback and comments

This list shows that a profile is more than just another namespace. In other words: if an ODRL policy is using an action from the IPTC RightsML profile does this mean all other specifications of our document (http://www.iptc.org/std/RightsML/1.1/RightsML_1.1EP2-spec_1.pdf) apply too?
And - as outlined in the raised issues - what if the RightsML and the anotherRightsML namespaces are used: will both Profiles apply and what if they have contradicting rules?

My recommendation: let's take the Profile discussion out of the single-namespace discussion.

Michael


> -----Original Message-----
> From: Myles, Stuart [mailto:SMyles@ap.org]
> Sent: Tuesday, November 12, 2013 5:48 PM
> To: ODRL Community Group
> Subject: RE: odrl-ISSUE-18: Single URI Namespace (Raising as an Issue)
> 
> ODRL v2 has a core model http://www.w3.org/community/odrl/two/model/
> and a common vocabulary http://www.w3.org/community/odrl/two/vocab/.
> As I understand it, having a single namespace in the ODRL Ontology unifies
> these two. So, where does that leave the idea of ODRL Profiles?
> http://www.w3.org/community/odrl/two/vocab/#section-3 That section
> specifically talks about "Declare your communities namespace" as being one
> of the things that you should do in creating a profile.
> 
> Namespaces generally support the concept of decentralized evolution. I
> don't think that a single namespace for both the data model and the
> common vocabulary prevents other namespaces from being used (such as
> IPTC's RightsML http://dev.iptc.org/RightsML). However, I don't think it
> exactly encourages it, either. Having one namespace for the model and one
> namespace for the common vocabulary would still be simple for authors of
> ODRL instances, I believe, but it would also encourage the use of ODRL
> profiles for particular use cases.
> 
> Regards,
> 
> Stuart
> 
> 
> -----Original Message-----
> From: ODRL Community Group Issue Tracker
> [mailto:sysbot+tracker@w3.org]
> Sent: Thursday, November 07, 2013 7:57 PM
> To: public-odrl@w3.org
> Subject: odrl-ISSUE-18: Single URI Namespace (Raising as an Issue)
> 
> odrl-ISSUE-18: Single URI Namespace (Raising as an Issue)
> 
> http://www.w3.org/community/odrl/track/issues/18
> 
> Raised by: Renato Iannella
> On product:
> 
> Dear all, now that we have released the draft ODRL Ontology [1] using a
> single namespace URI (http://www.w3.org/ns/odrl/2/) we need to decide
> on its adoption (or not) and update any existing draft documents.
> 
> The current draft ontology has used SKOS to define "groups" of concepts,
> like actions [2], so that human-readability is improved, and is not seen as one
> "flat-list" of terms.
> 
> Please express any views on this proposal to adopt the single URI namespace
> for all ODRL V2.0 encodings.
> 
> [1] http://www.w3.org/ns/odrl/2/
> [2] http://www.w3.org/ns/odrl/2/#term-actions
> 
> 
> 
> 
> 
> 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

Received on Wednesday, 13 November 2013 08:12:15 UTC