wiki-archive/twiki/temp-gjr/BDI/SDD/FederatingDescriptions.txt,v

head	1.8;
access;
symbols;
locks; strict;
comment	@# @;


1.8
date	2009.11.25.03.14.33;	author GarryJolleyRogers;	state Exp;
branches;
next	1.7;

1.7
date	2009.11.20.02.45.25;	author LeeBelbin;	state Exp;
branches;
next	1.6;

1.6
date	2007.03.06.17.30.00;	author TWikiGuest;	state Exp;
branches;
next	1.5;

1.5
date	2006.05.04.11.26.30;	author GregorHagedorn;	state Exp;
branches;
next	1.4;

1.4
date	2004.06.21.11.30.01;	author GregorHagedorn;	state Exp;
branches;
next	1.3;

1.3
date	2004.05.28.17.26.32;	author GregorHagedorn;	state Exp;
branches;
next	1.2;

1.2
date	2003.12.15.13.42.00;	author GregorHagedorn;	state Exp;
branches;
next	1.1;

1.1
date	2003.10.24.15.00.34;	author KevinThiele;	state Exp;
branches;
next	;


desc
@none
@


1.8
log
@none
@
text
@%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"}%
@


1.7
log
@none
@
text
@d1 1
a1 1
%META:TOPICINFO{author="LeeBelbin" date="1258685125" format="1.1" reprev="1.7" version="1.7"}%
d5 1
a5 1
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 &lt;ProjectDefinition&gt; 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.
d13 1
a13 1
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:
@


1.6
log
@Added topic name via script
@
text
@d1 2
d5 1
a5 3
%META:TOPICINFO{author="GregorHagedorn" date="1146741990" format="1.0" version="1.5"}%
%META:TOPICPARENT{name="ClosedTopicSchemaDiscussionSDD09"}%
We have been tempted in the past (I think) to view 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 &lt;ProjectDefinition&gt; 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.
d13 1
a13 1
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 SDD we currently call this envelope a "project". SDD should have no problem in the future providing a multi-project view, if descriptive data use the same terminology. You can have:
@


1.5
log
@none
@
text
@d1 2
@


1.4
log
@none
@
text
@d1 37
a37 36
%META:TOPICINFO{author="GregorHagedorn" date="1087817401" format="1.0" version="1.4"}%
%META:TOPICPARENT{name="SchemaDiscussionSDD09"}%
We have been tempted in the past (I think) to view 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 &lt;ProjectDefinition&gt; 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 SDD we currently call this envelope a "project". 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
@


1.3
log
@none
@
text
@d1 2
a2 2
%META:TOPICINFO{author="GregorHagedorn" date="1085765192" format="1.0" version="1.3"}%
%META:TOPICPARENT{name="SchemaDiscussion"}%
@


1.2
log
@none
@
text
@d1 1
a1 1
%META:TOPICINFO{author="GregorHagedorn" date="1071495720" format="1.0" version="1.2"}%
d37 1
@


1.1
log
@none
@
text
@d1 3
a3 3
%META:TOPICINFO{author="KevinThiele" date="1067007634" format="1.0" version="1.1"}%
%META:TOPICPARENT{name="LisbonTopicsForFurtherDiscussion"}%
We have been tempted in the past (I think) to view 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 &ltProject&gt 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.
d8 29
@