+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
> [1] you are proposing to drop it.
>
> Antoine
>
> [1] http://wiki.dublincore.org/index.php/DCAM_Revision_Scratchpad
> [2]http://www.w3.org/TR/rdf-sparql-query/#describe
> [3] http://www.w3.org/Submission/CBD/
>
>
>
>> Dear all,
>>
>> Some sources of confusion with the existing DCAM have been
>> terminological in
>> nature:
>>
>> -- overlap of DCAM with RDF terms, some of which are "false friends" [1]
>> (e.g., an "RDF statement" is not the same as a "DCAM statement");
>>
>> -- presence in the UML model of grouping mechanisms using "unusual"
>> terminology
>> (e.g., "surrogate");
>>
>> -- confusing distinction between entities representing "things in the
>> data"
>> (syntactic "slots" in a data record) and "things in the world"
>> (conceptual
>> things to which the information in the syntactic slots referred);
>>
>> -- local identifiers for subjects and objects (in RDF terms, for blank
>> nodes)
>> were out of scope of the DCAM Description Set Model per se, though
>> present
>> in DC-TEXT;
>>
>> -- subtle differences between the entities of DCAM's Description Set
>> Model
>> 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 [2] and would like to propose a radical
>> simplification.
>>
>> I propose to limit the entities of the DCMI Abstract Model to the
>> following,
>> 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):
>>
>> Record
>> DescriptionSet
>> Description
>> StatementSet - alternative suggestions welcome - this will require
>> discussion!!
>> DescribedResourceURI
>> DescribedResourceID - new!
>> PropertyURI
>> ValueURI
>> ValueID - new!
>> ValueString - re-defined with more restrictive meaning
>> ValueLabel
>> LanguageTag
>> SyntaxEncodingSchemeURI
>> SKOSConceptSchemeURI - proposed as equivalent replacement for
>> VocabularyEncodingSchemeURI
>>
>> 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
>> following):
>> PropertyURI + ValueURI
>> PropertyURI + ValueURI + SKOSConceptSchemeURI
>> PropertyURI + ValueURI + SKOSConceptSchemeURI + ValueLabel
>> PropertyURI + ValueURI + SKOSConceptSchemeURI + ValueLabel + LanguageTag
>> PropertyURI + ValueURI + SKOSConceptSchemeURI + ValueLabel +
>> SyntaxEncodingSchemeURI
>>
>> 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
>> theory
>> 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 [3].
>>
>> 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
>> would
>> 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
>> maintain
>> its existing "syntactic" entities (while dropping the "semantic"
>> entities in
>> favor of RDF) [4].
>>
>> Tom
>>
>> [1] http://en.wikipedia.org/wiki/False_friend
>> [2]
>> http://wiki.dublincore.org/index.php/DCAM_Revision_Scratchpad#Terminology_compared
>>
>> [3] http://www.w3.org/2011/rdf-wg/track/issues/27
>> [4] http://dublincore.org/architecturewiki/DCAM-2.0
>>
>
--
Kai Eckert
Universitätsbibliothek Mannheim
Stellv. Leiter Abteilung Digitale Bibliotheksdienste
Schloss Schneckhof West / 68131 Mannheim
Tel. 0621/181-2946 Fax 0621/181-2918
|