[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: Re: [tm-pubsubj] Call for vote on new deliverable structure
Lars Marius With some delay, I know will address the content of your arguments. > I haven't had time to look into this yet, but could you explain why > you would like to split this deliverable out from the original first > deliverable? My view on this has somehow matured. I think having a document gathering clear definitions and *minimal requirements* that publishers could easily meet is important to start the process of adoption of PSIs. As we have figured several times lately, there is a huge available legacy of identifiers that can be used almost *as they are* as PSIs, because they already meet those minimal requirements. It's important that people figure that those valuable PSIs already exist, that they meet the minimal requirements, and do not necessarily need heavy new process of publication, maybe just a little furbishing. > To me it sounds as though the first deliverable will contain very > little in the way of real substance ... Yes, there will be "very little" substance in that first deliverable, and that's exactly what we need. The less we have there, the better we are, because it will show that making a PSI is very simple if you want to just meet requirements, and that requirements are very few for PSIs to start to work. All the rest : format, structure, metadata, management, use ... is optimization, and I consider now it should stay at the level of recommendations and best practices, with no requirements in it. We have to pay much attention to what Suellen and/or Mary said about the publishing and library universe. They want something simple, and we have to show them that they are almost there, and don't need to pass through pages of arcane requirements to begin to set and use PSIs. > ... but that it will imply that we > know what to do in the second deliverable. No, if we consider documentation structure, format and metadata as only recommendations and not requirements. See my proposal in other message, I would like now to have only this first part to contain requirements, and the three others (Documentation, Management and Use) to contain only recommendations and best practices > If we publish deliverable > #1 first, that implies to me that we can't go back and change it. So > we shouldn't freeze it before we know what we'll do in deliverable > #2. But if we *do* know what to do in deliverable #2 why don't we just > do that at the same time? If Part 1 is requirements and Part 2 is only recommendations, then they have to be separated. > I don't see the point of this proposal. Several times already I've > seen people look at the current recommendations and be disappointed > because there is so little there. Now we seem to have decided that > the first deliverable is to contain almost nothing, and I don't think > that's a good idea. I disagree. A PSI is *almost nothing* indeed if you stick to basic requirements. And our documents have to show that (and first we have to be convinced ourselves) 1. Basically, it's dreadly simple, and requirements are very few. 2. In the details, there are many ways to do it, and a lot of devilish things to consider and care of, but none of them does impact really on the basic requirements. > I think that we are very close to ready to move on from the basic > principles that were agreed on in Barcelona and start on the real > work, which is now scheduled to be deliverable #2. I fear that if we > follow the proposed schedule we will > a) cause problems for ourselves by freezing a document containing > recommendations we don't understand the full implications of, and I think we are now mature enough to cast in stone the basic definitions and requirements > b) cause more problems for ourselves by getting bogged down in the > practicalities of finishing and polishing that document, rather > than moving forward to the real issues and actually making real > progress. I don't think we put the "real issues" at the same level. The real issue now is to have something simple, available for the world to stand upon :)) For example we could push that Part 1 to be an OASIS standard when it is adopted as a TC recommendation, but I don't think the following three parts should. Bernard ------------------------------------------------------------------- Bernard Vatant Consultant - Mondeca www.mondeca.com Chair - OASIS TM PubSubj Technical Committee www.oasis-open.org/committees/tm-pubsubj/ -------------------------------------------------------------------
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC