56 lines
2.8 KiB
Plaintext
56 lines
2.8 KiB
Plaintext
|
head 1.2;
|
||
|
|
access;
|
||
|
|
symbols;
|
||
|
|
locks; strict;
|
||
|
|
comment @# @;
|
||
|
|
|
||
|
|
|
||
|
|
1.2
|
||
|
|
date 2006.06.12.16.59.02; author BobMorris; state Exp;
|
||
|
|
branches;
|
||
|
|
next 1.1;
|
||
|
|
|
||
|
|
1.1
|
||
|
|
date 2006.06.12.16.54.30; author BobMorris; state Exp;
|
||
|
|
branches;
|
||
|
|
next ;
|
||
|
|
|
||
|
|
|
||
|
|
desc
|
||
|
|
@ualua
|
||
|
|
.
|
||
|
|
@
|
||
|
|
|
||
|
|
|
||
|
|
1.2
|
||
|
|
log
|
||
|
|
@
|
||
|
|
.
|
||
|
|
@
|
||
|
|
text
|
||
|
|
@Composite objects such as taxonomic descriptions, images, and raw XML which may live in databases have some of their parts mutable and some immutable. It is complicated to store the entire representation in the data, then have some kinds of pointers from metadata explaining which of those may have changed and require, e.g. a new version to be fetched. On the other hand, if one puts everything in the LSID metadata, then, in general, nothing about immutability can be assumed unless there are provided some rules or other agreed upon mechanisms for specifying what is mutable. Absence of this can make collaborations across time space diffficult.
|
||
|
|
|
||
|
|
One solution proposed is that all metadata is regarded as mutable, and any time a group of agents wishes to have a conversation about a given LSID'd object, it is "checked out" and a new LSID issued to that object perhaps with reference to the original.
|
||
|
|
|
||
|
|
Two secondary issues arose: RDF is not rich enough to describe all the concerns of descriptive data (e.g. continuous data) and bytewise equality may not always be a useful criterion for when two datasets are the same. (Examples include: Serialization changes, e.g. two different lossless image encodings or two different orderings of an XML sequence which for which schema annotation has declared the order doesn't matter).
|
||
|
|
|
||
|
|
There was some agreement that it is worth proceding in the face of these impediments to see how great they are.
|
||
|
|
|
||
|
|
Bob Morris, Jessie Kennedy, Damien Barnier, Tim Robertson
|
||
|
|
@
|
||
|
|
|
||
|
|
|
||
|
|
1.1
|
||
|
|
log
|
||
|
|
@Initial revision
|
||
|
|
@
|
||
|
|
text
|
||
|
|
@d1 1
|
||
|
|
a1 1
|
||
|
|
Composite objects such as taxonomic descriptions, images, and raw XML which may live in databases have some of their parts mutable and some immutable. It is complicated to store the entire represengtation in the data, then have some kinds of pointers from metadata explaining which of those may have changed and require, e.g. a new version to be fetched. On the other hand, if one puts everything in the LSID metadata, then, in general, nothing about immutability can be assumed unless there are provided some rules or other agreed upon mechanisms for specifying what is mutable. Absence of this can make collaborations across time space diffficult.
|
||
|
|
d5 1
|
||
|
|
a5 1
|
||
|
|
Two secondary issues arose: RDF is not rich enough to describe all the concerns of descriptive data (e.g. continuous data) and bytewise equality may not always be a useful criterion for when two datasets are the same. (Examples include two different lossless image encodings or two different orderings of an XML sequence which for which schema annotation has declared the order doesn't matter).
|
||
|
|
d7 1
|
||
|
|
@
|