41 lines
2.4 KiB
Plaintext
41 lines
2.4 KiB
Plaintext
|
%META:TOPICINFO{author="GarryJolleyRogers" date="1259118873" format="1.1" version="1.8"}%
|
||
|
|
%META:TOPICPARENT{name="ClosedTopicSchemaDiscussionSDD09"}%
|
||
|
|
---+!! %TOPIC%
|
||
|
|
|
||
|
|
We have been tempted in the past (I think) to view BDI.SDD_ documents as projects in the old DELTA and Lucid senses - as isolated projects with an author, revision status etc. For some documents this will still be the case, with metadata for such documents handled by the <ProjectDefinition> tags. But consider a future where I have a database with descriptions of all the genera of plants of the world. Authors of descriptions are updating and managing individual descriptions in that database. Someone queries the database and I serve up 10 of the descriptions - in this case, what's the project and what's the meaning of e.g. "project revision status", "project last update date" etc.
|
||
|
|
|
||
|
|
So, we need to maintain equivalent metadata at the individual description level to accommodate this.
|
||
|
|
|
||
|
|
-- Main.KevinThiele - 24 Oct 2003
|
||
|
|
|
||
|
|
---
|
||
|
|
|
||
|
|
I believe that a project makes sense whether you have a federation or not. A federation may consist of multiple projects, but still issues of IPR and copyright, data access etc. are probably best managed in the form of some envelopes for data. In BDI.SDD_ we currently call this envelope a "project". BDI.SDD_ should have no problem in the future providing a multi-project view, if descriptive data use the same terminology. You can have:
|
||
|
|
|
||
|
|
<pre>
|
||
|
|
Project 1
|
||
|
|
Terminology only
|
||
|
|
(perhaps plus common resources, as used in terminology)
|
||
|
|
|
||
|
|
Project 2
|
||
|
|
Specimen descriptions
|
||
|
|
|
||
|
|
Project 3
|
||
|
|
Taxon descriptions
|
||
|
|
Taxon keys
|
||
|
|
|
||
|
|
Project 4
|
||
|
|
more taxon descriptions
|
||
|
|
|
||
|
|
etc.</pre>
|
||
|
|
|
||
|
|
(The exact details of this have to be worked out, probably it is not yet fully functional - any input is appreciated. But, this is my picture of the future, where I think we are heading and how it could work.)
|
||
|
|
|
||
|
|
Note that currently we can express copyright and licenses only through the project envelope.
|
||
|
|
|
||
|
|
Is this too restrictive? I currently view it as beneficial, to reduce the overhead that is otherwise produced by sorting out the legal aspects of copyright issues. Sorting copyright of a dataset where 1000 descriptions all have a different copyright, each copyright remaining perhaps at the author, is probably a nightmare.
|
||
|
|
|
||
|
|
Gregor Hagedorn - 15 Dec 2003
|
||
|
|
|
||
|
|
%META:TOPICMOVED{by="GregorHagedorn" date="1085765192" from="SDD.DataSnapshots" to="SDD.FederatingDescriptions"}%
|