wiki-archive/twiki/data/UBIF/ContentMetadataSearchingNam...

346 lines
16 KiB
Plaintext

head 1.13;
access;
symbols;
locks; strict;
comment @# @;
1.13
date 2009.11.25.03.14.41; author GarryJolleyRogers; state Exp;
branches;
next 1.12;
1.12
date 2009.11.20.02.35.36; author LeeBelbin; state Exp;
branches;
next 1.11;
1.11
date 2007.03.06.17.30.00; author TWikiGuest; state Exp;
branches;
next 1.10;
1.10
date 2004.08.13.12.41.00; author GregorHagedorn; state Exp;
branches;
next 1.9;
1.9
date 2004.08.13.10.40.00; author GregorHagedorn; state Exp;
branches;
next 1.8;
1.8
date 2004.07.15.19.58.00; author GregorHagedorn; state Exp;
branches;
next 1.7;
1.7
date 2004.07.15.18.04.00; author GregorHagedorn; state Exp;
branches;
next 1.6;
1.6
date 2004.06.11.10.15.49; author GregorHagedorn; state Exp;
branches;
next 1.5;
1.5
date 2004.06.11.09.14.27; author GregorHagedorn; state Exp;
branches;
next 1.4;
1.4
date 2004.06.10.10.15.55; author DonaldHobern; state Exp;
branches;
next 1.3;
1.3
date 2004.06.10.08.40.00; author GregorHagedorn; state Exp;
branches;
next 1.2;
1.2
date 2004.06.09.17.49.47; author GregorHagedorn; state Exp;
branches;
next 1.1;
1.1
date 2004.06.01.08.54.46; author GregorHagedorn; state Exp;
branches;
next ;
desc
@none
@
1.13
log
@none
@
text
@%META:TOPICINFO{author="GarryJolleyRogers" date="1259118881" format="1.1" version="1.13"}%
%META:TOPICPARENT{name="UBIF.SchemaDiscussion"}%
---+!! %TOPIC%
Whereas derivations record the online generation/transformations actions of providers and portals (see UBIF.DerivationHistory), another element provides metadata about the data collection from which the current data is derived. These metadata include ownership, intellectual property rights, author/editorship, revision status, a title, description, coverage, etc.
Specifically, some items provided here are ambiguous insofar as that they may refer to the base data collection, or to the potentially highly reduced set provided in the current data set. If a multiauthored and worldwide database delivers a single description in an BDI.SDD_ dataset, the authors, revision status, geographic scope, etc. are not specific to the data being delivered. Requiring that would put an undue strain on the data providers.
At the BDI.SDD_ meeting in Berlin we found it difficult to coin a name for this. Clearly, <nop>DatasetMetadata or just <nop>Metadata is appropriate in the xml tree, but strongly misleading in regard to the scope of the metadata (= underlying dataset rather than current/filtered/transformed). BDI.SDD_ in previous versions called this element <nop>ProjectDefinition, and in BDI.SDD_.CurrentSchemaVersion 0.91 beta 16 it is called <nop>ProjectMetadata. I don't really find "project" intuitive, but so far it seems to work better than most other qualifiers.
A fully descriptive term might be: <nop>UnderlyingDataCollectionMetadata...
Please express your preferences or provide new alternatives. This is urgent, such base level terms are really hard to debug out of all annotations, documentation, example files, and xslt that has to be written!
-- [[Main.GregorHagedorn][Gregor Hagedorn]] - 01 Jun 2004
Walter Berendsohn and I discussed this issue today. Walter has reservations about <nop>DataCollection, because it may be misunderstood as referring to the activity rather then the result. We considered <nop>PrincipalSourceMetadata and decided that perhaps just <nop><strong>SourceMetadata</strong> with appropriate annotations may be the best choice. Please do comment if you have reservations about this!
-- [[Main.GregorHagedorn][Gregor Hagedorn]] - 9 Jun 2004
---
I have no problem with <nop>SourceMetadata.
-- Main.DonaldHobern - 10 Jun 2004
---
<nop><strong>SourceMetadata</strong> is fine from a consumer perspective, indicating that the scope may be larger than what is delivered. It is somewhat weak from the perspective of the principle provider. If I am exporting a DELTA or Lucid data set to BDI.SDD_, defining that I am author of the Source - when the delivered thing is the whole thing - seems weak -- but perhaps acceptable?
I don't know, perhaps leaving the element name simply at "Metadata" is the best choice, it is ambiguous, but the does not depend on perspective as the <nop>SourceMetadata disambiguation...
-- [[Main.GregorHagedorn][Gregor Hagedorn]] - 20 Jun 2004
---
%META:TOPICMOVED{by="GregorHagedorn" date="1092400721" from="UBIF.SourceMetadataSearchingName" to="UBIF.ContentMetadataSearchingName"}%
@
1.12
log
@none
@
text
@d1 1
a1 1
%META:TOPICINFO{author="LeeBelbin" date="1258684536" format="1.1" reprev="1.12" version="1.12"}%
d7 1
a7 1
Specifically, some items provided here are ambiguous insofar as that they may refer to the base data collection, or to the potentially highly reduced set provided in the current data set. If a multiauthored and worldwide database delivers a single description in an BDI.SDD dataset, the authors, revision status, geographic scope, etc. are not specific to the data being delivered. Requiring that would put an undue strain on the data providers.
d9 1
a9 1
At the BDI.SDD meeting in Berlin we found it difficult to coin a name for this. Clearly, <nop>DatasetMetadata or just <nop>Metadata is appropriate in the xml tree, but strongly misleading in regard to the scope of the metadata (= underlying dataset rather than current/filtered/transformed). BDI.SDD in previous versions called this element <nop>ProjectDefinition, and in BDI.SDD.CurrentSchemaVersion 0.91 beta 16 it is called <nop>ProjectMetadata. I don't really find "project" intuitive, but so far it seems to work better than most other qualifiers.
d27 1
a27 1
<nop><strong>SourceMetadata</strong> is fine from a consumer perspective, indicating that the scope may be larger than what is delivered. It is somewhat weak from the perspective of the principle provider. If I am exporting a DELTA or Lucid data set to BDI.SDD, defining that I am author of the Source - when the delivered thing is the whole thing - seems weak -- but perhaps acceptable?
@
1.11
log
@Added topic name via script
@
text
@d1 2
a4 2
%META:TOPICINFO{author="GregorHagedorn" date="1092400860" format="1.0" version="1.10"}%
%META:TOPICPARENT{name="UBIF.SchemaDiscussion"}%
d7 1
a7 1
Specifically, some items provided here are ambiguous insofar as that they may refer to the base data collection, or to the potentially highly reduced set provided in the current data set. If a multiauthored and worldwide database delivers a single description in an SDD dataset, the authors, revision status, geographic scope, etc. are not specific to the data being delivered. Requiring that would put an undue strain on the data providers.
d9 1
a9 1
At the SDD meeting in Berlin we found it difficult to coin a name for this. Clearly, <nop>DatasetMetadata or just <nop>Metadata is appropriate in the xml tree, but strongly misleading in regard to the scope of the metadata (= underlying dataset rather than current/filtered/transformed). SDD in previous versions called this element <nop>ProjectDefinition, and in SDD.CurrentSchemaVersion 0.91 beta 16 it is called <nop>ProjectMetadata. I don't really find "project" intuitive, but so far it seems to work better than most other qualifiers.
d27 1
a27 1
<nop><strong>SourceMetadata</strong> is fine from a consumer perspective, indicating that the scope may be larger than what is delivered. It is somewhat weak from the perspective of the principle provider. If I am exporting a DELTA or Lucid data set to SDD, defining that I am author of the Source - when the delivered thing is the whole thing - seems weak -- but perhaps acceptable?
d34 1
@
1.10
log
@none
@
text
@d1 2
@
1.9
log
@none
@
text
@d1 1
a1 1
%META:TOPICINFO{author="GregorHagedorn" date="1092393600" format="1.0" version="1.9"}%
d7 1
a7 1
At the SDD meeting in Berlin we found it difficult to coin a name for this. Clearly, <nop>DatasetMetadata or just <nop>Metadata is appropriate in the xml tree, but strongly misleading in regard to the scope of the metadata (= underlying dataset rather than current/filtered/transformed). SDD in previous versions called this element ProjectDefinition, and in SDD.CurrentSchemaVersion 0.91 beta 16 it is called <nop>ProjectMetadata. I don't really find "project" intuitive, but so far it seems to work better than most other qualifiers.
d15 1
a15 1
Walter Berendsohn and I discussed this issue today. Walter has reservations about <nop>DataCollection, because it may be misunderstood as referring to the activity rather then the result. We considered <nop>PrincipalSourceMetadata and decided that perhaps just <nop><strong>ContentMetadata</strong> with appropriate annotations may be the best choice. Please do comment if you have reservations about this!
d20 1
a20 1
I have no problem with <nop>UBIF.ContentMetadata.
d25 1
a25 1
<nop><strong>ContentMetadata</strong> is fine from a consumer perspective, indicating that the scope may be larger than what is delivered. It is somewhat weak from the perspective of the principle provider. If I am exporting a DELTA or Lucid data set to SDD, defining that I am author of the Source - when the delivered thing is the whole thing - seems weak -- but perhaps acceptable?
d27 1
a27 1
I don't know, perhaps leaving the element name simply at "Metadata" is the best choice, it is ambiguous, but the does not depend on perspective as the <nop>ContentMetadata disambiguation...
d29 1
a29 1
-- [[Main.GregorHagedorn][Gregor Hagedorn]] - 9 Jun 2004
d32 1
a32 1
%META:TOPICMOVED{by="GregorHagedorn" date="1089921392" from="SDD.SourceMetadataSearchingName" to="UBIF.SourceMetadataSearchingName"}%
@
1.8
log
@none
@
text
@d1 1
a1 1
%META:TOPICINFO{author="GregorHagedorn" date="1089921480" format="1.0" version="1.8"}%
d15 1
a15 1
Walter Berendsohn and I discussed this issue today. Walter has reservations about <nop>DataCollection, because it may be misunderstood as referring to the activity rather then the result. We considered <nop>PrincipalSourceMetadata and decided that perhaps just <nop><strong>SourceMetadata</strong> with appropriate annotations may be the best choice. Please do comment if you have reservations about this!
d20 1
a20 1
I have no problem with <nop>UBIF.SourceMetadata.
d25 1
a25 1
<nop><strong>SourceMetadata</strong> is fine from a consumer perspective, indicating that the scope may be larger than what is delivered. It is somewhat weak from the perspective of the principle provider. If I am exporting a DELTA or Lucid data set to SDD, defining that I am author of the Source - when the delivered thing is the whole thing - seems weak -- but perhaps acceptable?
d27 1
a27 1
I don't know, perhaps leaving the element name simply at "Metadata" is the best choice, it is ambiguous, but the does not depend on perspective as the <nop>SourceMetadata disambiguation...
@
1.7
log
@none
@
text
@d1 1
a1 1
%META:TOPICINFO{author="GregorHagedorn" date="1089914640" format="1.0" version="1.7"}%
d7 1
a7 1
At the SDD meeting in Berlin we found it difficult to coin a name for this. Clearly, <nop>DatasetMetadata or just <nop>Metadata is appropriate in the xml tree, but strongly misleading in regard to the scope of the metadata (= underlying dataset rather than current/filtered/transformed). SDD in previous versions called this element ProjectDefinition, and in CurrentSchemaVersion 0.91 beta 16 it is called <nop>ProjectMetadata. I don't really find "project" intuitive, but so far it seems to work better than most other qualifiers.
d15 1
a15 1
Walter Berendsohn and I discussed this issue today. Walter has reservations about <nop>DataCollection, because it may be misunderstood as referring to the activity rather then the result. We considered <nop>PrincipalSourceMetadata and decided that perhaps just <nop><strong>UBIF.SourceMetadata</strong> with appropriate annotations may be the best choice. Please do comment if you have reservations about this!
d25 3
a27 1
<nop><strong>UBIF.SourceMetadata</strong> is fine from a consumer perspective, indicating that the scope may be larger than what is deliverd. It is somewhat weak from the perspective of the principle provider. If I am exporting a DELTA or Lucid data set to SDD, defining that I am author of the Source - when the delivered thing is the whole thing - seems weak -- but perhaps acceptable?
d32 1
a32 1
%META:TOPICMOVED{by="GregorHagedorn" date="1086856742" from="SDD.DatasetMetadataSearchingName" to="SDD.SourceMetadataSearchingName"}%
@
1.6
log
@none
@
text
@d1 3
a3 3
%META:TOPICINFO{author="GregorHagedorn" date="1086948949" format="1.0" version="1.6"}%
%META:TOPICPARENT{name="UnifiedBioInfoFramework"}%
Whereas derivations record the online generation/transformations actions of providers and portals (see DerivationHistory), another element provides metadata about the data collection from which the current data is derived. These metadata include ownership, intellectual property rights, author/editorship, revision status, a title, description, coverage, etc.
d15 1
a15 1
Walter Berendsohn and I discussed this issue today. Walter has reservations about <nop>DataCollection, because it may be misunderstood as referring to the activity rather then the result. We considered <nop>PrincipalSourceMetadata and decided that perhaps just <nop><strong>SourceMetadata</strong> with appropriate annotations may be the best choice. Please do comment if you have reservations about this!
d20 1
a20 1
I have no problem with <nop>SourceMetadata.
d25 1
a25 1
<nop><strong>SourceMetadata</strong> is fine from a consumer perspective, indicating that the scope may be larger than what is deliverd. It is somewhat weak from the perspective of the principle provider. If I am exporting a DELTA or Lucid data set to SDD, defining that I am author of the Source - when the delivered thing is the whole thing - seems weak -- but perhaps acceptable?
@
1.5
log
@none
@
text
@d1 2
a2 2
%META:TOPICINFO{author="GregorHagedorn" date="1086945267" format="1.0" version="1.5"}%
%META:TOPICPARENT{name="OverarchingPatternsForTdwgSchemata"}%
@
1.4
log
@none
@
text
@d1 1
a1 1
%META:TOPICINFO{author="DonaldHobern" date="1086862555" format="1.0" version="1.4"}%
d22 8
a29 2
-- Main.DonaldHobern - 10 Jun 2004
@
1.3
log
@none
@
text
@d1 1
a1 1
%META:TOPICINFO{author="GregorHagedorn" date="1086856800" format="1.0" version="1.3"}%
d19 5
@
1.2
log
@none
@
text
@d1 1
a1 1
%META:TOPICINFO{author="GregorHagedorn" date="1086803387" format="1.0" version="1.2"}%
d7 1
a7 1
At the SDD meeting in Berlin we found it difficult to coin a name for this. Clearly, <nop>DatasetMetadata or just <nop>Metadata is appropriate in the xml tree, but strongly misleading in regard to the scope of the metadata (underlying dataset rather than current/filtered/transformed). SDD in previous versions called this element ProjectDefinition, and in CurrentSchemaVersion 0.91 beta 16 it is called <nop>ProjectMetadata. I don't really find "project" intuitive, but so far it seems to work better than most other qualifiers.
d18 2
a19 2
---
@
1.1
log
@none
@
text
@d1 1
a1 1
%META:TOPICINFO{author="GregorHagedorn" date="1086080086" format="1.0" version="1.1"}%
d3 1
a3 1
Whereas derivations record the online generation/transformation and actions of portals (see DerivationHistory), another element provides metadata about the data collection from which the current data is derived. These metadata include ownership, intellectual property rights, author/editorship, revision status, a title, description, coverage, etc.
d7 1
a7 1
At the SDD meeting in Berlin we found it difficult to coin a name for this. Clearly, <nop>DatasetMetadata is appropriate in the xml tree, but strongly misleading in regard to the scope of the metadata (underlying dataset rather than current/filtered/transformed). SDD in previous versions called this element ProjectDefinition, and in CurrentSchemaVersion 0.91 beta 16 it is called <nop>ProjectMetadata. I don't really find project intuitive, but so far it seems to work better than most other qualifiers.
d14 6
@