- From: Smith, Kevin, VF-Group <Kevin.Smith@vodafone.com>
- Date: Wed, 4 Apr 2007 12:32:23 +0200
- To: <public-ddwg@w3.org>
Thanks Rotan. Consistency is a use case which I can add to the Repository document. Rollback should be a Repository requirement, and that implicitly involves versioning. Versioning applies to values, but maybe also property names? I can only think that would be because of an error in the original name. As you say, a user may decide to stick with the old name for backward compatibility. If that happens then another complication is added: should a query to the old property name return the value last assigned to that property name, or the latest value assigned to the new property name? Versioning of the vocabulary would fall under the scope of that document (although the Repository document may make reference to it). The final trust example will also be a Repository use case, and will include the requirements for data authenticity/validity/traceability. Cheers Kevin -----Original Message----- From: public-ddwg-request@w3.org [mailto:public-ddwg-request@w3.org] On Behalf Of Rotan Hanrahan Sent: 04 April 2007 11:09 To: public-ddwg@w3.org Subject: RE: [REP] Data versioning First thoughts.... Versioning is for consistency (I may decide to stick with a certain version because I have evidence that it works for my business use cases and I fear anything that might try to "correct" this). Versioning is for rollback (if my fears are realized). Versioning is for efficient replication/caching (so that I don't keep making copies of what I already have). Versioning applies to values (as the most likely changes in the bulk of the data will occur because of corrections of past errors). Versioning could apply to the vocabulary or ontology (because these will evolve, not just grow, because we are not gods who can foresee all possible future issues, no matter how hard we try). The last one is something we should think about carefully. This could be the most difficult issue regarding versioning. Finally, the data in the DDR could come from multiple sources, even for the same properties. For example, my company does extensive tests on dozens of new devices every month, and so do my competitors. Naturally, we expect our analysis to produce the same results, but this is the real world and we know that any of us can make an error. We may make (a subset of) our collection available (to the public) via a compliant DDR API. So may our colleagues (a.k.a. competitors who also believe that doing so will benefit everyone and is the right thing to do). This produces an overlap in sources of information, but individual consumers of the data can decide (based on trust, availability, efficiency, cost, national allegiance, politics, favouritism etc.) to chose one source over another. In a fair market, this is to be expected. The DDR should permit this mode of operation. ---Rotan. -----Original Message----- From: public-ddwg-request@w3.org [mailto:public-ddwg-request@w3.org] On Behalf Of Smith, Kevin, VF-Group Sent: 04 April 2007 10:48 To: public-ddwg@w3.org Subject: [REP] Data versioning Hi all, I have the following requirement in the Repository Requirements document: ==== [DDR-DATA-VERSIONING] ==== (original text): The DDR MUST provide the capability to fulfil data versioning, where data includes but is not limited to device descriptions and their device properties. (New text): The DDR MUST support versioning, either inherently or via another system, of device descriptions. My questions are: How will this work in practice? Are there use cases for having two or more valid/correct device profiles in existence for the same device? Versioning implies a new value for a given property, not a different set of properties. Or is this simply to provide a rollback mechanism to a previous version? Cheers Kevin
Received on Wednesday, 4 April 2007 10:32:31 UTC