+1 for the issue tracker!
Am 04.01.2012 14:39, schrieb Antoine Isaac:
> Hi Tom,
> That's quite many things, maybe some splitting would help. Btw wasn't
> there talks about an issue tracker?
> Anyway, for now I'd just like to ask about the fate of Record. It is in
> the mail below in the entities that are kept, but in another mail and in
>  you are proposing to drop it.
>  http://wiki.dublincore.org/index.php/DCAM_Revision_Scratchpad
>  http://www.w3.org/Submission/CBD/
>> Dear all,
>> Some sources of confusion with the existing DCAM have been
>> terminological in
>> -- overlap of DCAM with RDF terms, some of which are "false friends" 
>> (e.g., an "RDF statement" is not the same as a "DCAM statement");
>> -- presence in the UML model of grouping mechanisms using "unusual"
>> (e.g., "surrogate");
>> -- confusing distinction between entities representing "things in the
>> (syntactic "slots" in a data record) and "things in the world"
>> things to which the information in the syntactic slots referred);
>> -- local identifiers for subjects and objects (in RDF terms, for blank
>> were out of scope of the DCAM Description Set Model per se, though
>> in DC-TEXT;
>> -- subtle differences between the entities of DCAM's Description Set
>> and entities of the DC-TEXT language.
>> I have mapped the terminologies of the DCAM Description Set Model,
>> DC-TEXT, and
>> RDF in a table in the wiki  and would like to propose a radical
>> I propose to limit the entities of the DCMI Abstract Model to the
>> and to use the same names for a DC-TEXT-inspired notation (which could be
>> folded into the "technical" DCAM document and used for examples):
>> StatementSet - alternative suggestions welcome - this will require
>> DescribedResourceID - new!
>> ValueID - new!
>> ValueString - re-defined with more restrictive meaning
>> SKOSConceptSchemeURI - proposed as equivalent replacement for
>> I propose to _drop_ the following as entities of the DCAM Description
>> Set Model and
>> DC-TEXT language and to use them simply in illustrative patterns:
>> Value Surrogate
>> Non-Literal Value Surrogate
>> Literal Value Surrogate
>> Plain Value String
>> Typed Value String
>> The Descriptive Patterns (or Design Patterns) could illustrate selected
>> combinations of DCAM "slots":
>> Minimal DescriptionSet
>> One Description with one StatementSet and no DescribedResourceURI
>> DescriptionSet with multiple Descriptions
>> Connected via DescribedResourceURI and ValueURI
>> Connected via DescribedResourceID and ValueID
>> Statements of the "Literal Value Pattern"
>> PropertyURI + ValueString
>> PropertyURI + ValueString + LanguageTag
>> PropertyURI + ValueString + SyntaxEncodingSchemeURI
>> Statements of the "Non-Literal Value Pattern" (pick three of the
>> PropertyURI + ValueURI
>> PropertyURI + ValueURI + SKOSConceptSchemeURI
>> PropertyURI + ValueURI + SKOSConceptSchemeURI + ValueLabel
>> PropertyURI + ValueURI + SKOSConceptSchemeURI + ValueLabel + LanguageTag
>> PropertyURI + ValueURI + SKOSConceptSchemeURI + ValueLabel +
>> I also propose to _drop_ all of the "thing-in-the-world" entities in
>> the DCAM
>> Description Set Model: Described Resource, Property, Non-literal
>> Value, Literal
>> Value, Vocabulary Encoding Scheme, and Syntax Encoding Scheme. The
>> idea here
>> is to limit the DCAM Description Set Model to "syntactic slots"
>> ("things in the
>> data") and point off to RDF, with its semantics, for the underlying
>> about the "things in the world" to which metadata refers.
>> I also propose to make dcam:memberOf equivalent to skos:inScheme and
>> dcam:VocabularyEncodingScheme equivalent to skos:ConceptScheme -- then
>> use the
>> latter. We should consider using rdfs:label instead of rdf:value
>> depending on
>> what the current RDF Working Group decides re: best practice
>> guidelines .
>> Note that overall, the idea would be to keep the core model
>> bone-simple and
>> push some of the things out of the current core model into "descriptive
>> patterns" that could be used as the basis of examples. The idea would
>> also be
>> to align the DCAM Description Set Model perfectly with DC-TEXT, which
>> be used for the descriptive patterns.
>> Also note that this proposal would mean changing the "interface" of
>> the current
>> DCAM by pushing the Literal/Non-Literal Value Surrogates out of the
>> core model
>> and replacing them with less formalized "descriptive patterns". See, for
>> contrast, Mikael's 2008 proposal for revising DCAM in a way that would
>> its existing "syntactic" entities (while dropping the "semantic"
>> entities in
>> favor of RDF) .
>>  http://en.wikipedia.org/wiki/False_friend
>>  http://www.w3.org/2011/rdf-wg/track/issues/27
>>  http://dublincore.org/architecturewiki/DCAM-2.0
Stellv. Leiter Abteilung Digitale Bibliotheksdienste
Schloss Schneckhof West / 68131 Mannheim
Tel. 0621/181-2946 Fax 0621/181-2918