37 lines
3.6 KiB
Plaintext
37 lines
3.6 KiB
Plaintext
%META:TOPICINFO{author="GarryJolleyRogers" date="1259118874" format="1.1" version="1.10"}%
|
|
%META:TOPICPARENT{name="SchemaChangeLog09beta29"}%
|
|
---+!! %TOPIC%
|
|
|
|
We previously had a complex data structure that allowed to contain partial dates, e.g. if only the year is known. In BDI.SDD_ 0.9 beta 29 (see SchemaChangeLog09beta29) this was removed in an attempt to simplify the schema. The following problem persists, however and needs to be discussed:
|
|
|
|
Legacy data (e.g. DELTA) often have no known initiation or first publication date of projects. However, in many aspects, an imported DELTA datasets will be richer, and the import will probably be a semi-automatic process where information (especially about authorship, language, and copyright) will have to be filled in in a dialog by a human curator of the data. In that sense it seems reasonable that the imported data should be considered a new version of the legacy dataset. As a consequence, the full data in Version/PublicationDate would always be available.
|
|
|
|
Is this acceptable?
|
|
|
|
On the other hand, in <nop>UBIF.ContentMetadata/<nop>RevisionData we have an <nop>InitiationDate that is so far required. As a consequence, for legacy projects that are imported and where the original publication date is known only to the year, there will be no place in BDI.SDD_ to enter the year. The first publication year can only be entered as part of the copyright statement. Will this be sufficient?
|
|
|
|
Question: should the <nop>InitiationDate remain required? Or should there be alternatives between date and unconstrained string?
|
|
|
|
Gregor Hagedorn - 28 Nov 2003
|
|
---
|
|
|
|
I'm neutral on whether it should be required, but I really hate the possibility of an unconstrained string, because it becomes almost useless for machine processing. (Was this project initiated before or after that one? Does "prior to 1800" mean the same as "prior to 1900"? Is "unknown" the same as "unspecified"?...). I'd almost rather see a type sdd:Date that is a union of a few standard XML dates and perhaps a single enumerated constant "unspecified".
|
|
|
|
A problem with that approach is that it is difficult to tell the type of a polymorphic object in XML. I believe that the only thing possible is to make (yet another) required attribute like xsi:type to reveal which derived type an object has. I think that addresses validation of derived types. But maybe a required attribute on an optional object isn't that bad.
|
|
|
|
Bob
|
|
---
|
|
|
|
I believe there is another option, a required initiationDate where the value could be an unconstrained string but with an optional attribute of fixed date type. That way, much as in the character specification, there can be a natural language string that is not necessarily interpretable by machine but there is an associated field with machine readable information.
|
|
|
|
Bryan Heidorn - April 1, 2004
|
|
---
|
|
|
|
For the time being I have made the <nop>RevisionData/InitiationDate optional rather than polymorphisms of date plus string, which seem currently to me to be too much complication for relatively little gained. We would need a good use case to argue for the polymorphic situations.
|
|
|
|
<nop>InitiationDate now has the following annotation: "Date/time when the object (project, term definition, description, etc.) was initiated. Applications may initially set this to the system date for new objects, but authors must be able to change it to an earlier date if necessary. It may be missing for legacy data. In this case, earlier versions in other data formats should be mentioned in the IPR copyright, acknowledgement, etc. statements."
|
|
|
|
OK?
|
|
|
|
Gregor Hagedorn - 26 May 2004
|
|
--- |