[rights-requirements] SBL Objections Outline

[Patrick Durusau <pdurusau@emory.edu>]

Hari,

Apologies for the late posting. I got back from Chicago on Friday very 
ill and spent the last two days sleeping for the most part. Trying to 
recover from a very bad cold/cough so I won't have to stay on mute most 
of Wednesday.

I went beyond simply listing our objections to offer what I hope are 
some constructive suggestions for how to go forward. I am not wedded to 
any of the suggestions and consider them more conversation starters than 
fixed or positions to be defended. All suggestions and comments welcome.

I have attached the outline as a plain ASCII file for those who don't 
want to fire up Open Office to read it.

Hope everyone is having a great day and feeling better than I do at the 
moment.

Patrick

-- 
Patrick Durusau
Director of Research and Development
Society of Biblical Literature
pdurusau@emory.edu
Co-Editor, ISO Reference Model for Topic Maps


Outline of SBL Objections 

(does not include specific objections to R01, R02, R03, R04, R11, R16, R20 (language architecture); R06 (architectural features); R06/SX02, R07/SX03, R08/SX04, R10/SX05 (redundancy), R07/SX03 (lack of clarity on XML Schema); SX06, SX07, SX08, SX09, SX10, SX12, SX13 (domain specific extensions)

1. Royalty Free as out of scope: 

This TC has been charged with developing an language for expressing digital rights. It has not been chartered to develop a digital rights system. A royalty free digital rights language, separate and apart from any digital rights system, will promote the use of and development of systems for a digital rights language developed by this TC. It is a legitmate requirement and should not be considered as "out of scope" for this TC.

2. Inadequate Requirements Gathering:

The original requirements period for this TC was inconsistent with it charter to support a "wide variety of business models" since it allowed a grossly inadequate time period to develop requirements from business communities such as healthcare and financial services, as well as libraries on the more academic side. Unfortunately, for all parties to the TC, including the SBL, the debate over the requirements gathering took on a life of its own, which has consumed weary hours of the TC's time without producing either a consensus in the TC or more requirements for the TC to consider.

Let's simply assume that the original time for requirements was an effort to meet an outside deadline in a non-OASIS forum. That process has gone its own way and the original motivation to close requirements early no longer obtains. I would suggest that we work very diligently on the requirements we have, which need not be complete in order for the examples sub-committee to do its work, and at the same time, re-open the requirements process. I think we will find that most of the requirements have already been submitted and what will come in will actually be use cases that will help test the rights expression language. 

3. Inadequate Requirements Process:

There has not been an agreed upon procedure for reaching conclusions on any of the requirements filed with the TC. Rather than going over old disagreements, I would suggest that we formulate a means by which we can reach and record a concensus on requirements. That will require all parties to be willing to accomodate each other, just as happens in any standards process. There are no requirements that are self evident (outside of those we support) and we should recognize that others probably feel the same way about their requirements. 

(Specific objections to the current requirements appear here)

4. Definition of Terms:

In a nutshell, the requirements document relies upon the already drafted XrML for its terms. While it is conceded that XrML is the basis for this TC's work product, it seems odd to have the language from which requirements are being drafted in a public forum to control the expression of those requirements. I would hope that a public requirements process would result in a stronger XrML than it was when this process began. That is unlikely if XrML defines the scope and range of the requirements.

5. Dispositioning of SBL Requirements:

The problem with using the pre-defined categories from XrML is highlighted by the "dispositioning" of various SBL requirements. Those requirements are so tied to XrML and so broad that it would be difficult to imagine a rights expression language that could not be said to meet them. Meaningful requirements, based upon the requirements already submitted and hopefully those to be submitted, should be reviewed and requirements derived from those submissions. That is far different from taking submissions and placing them in pre-determined categories of requirements.