- AMIssues

Issues with (and suggested changes to) the DCMI Abstract Model

This page contains a list of possible issues with (and suggested changes to) the DCMI Abstract Model.

Definition of 'term'

Various people, 2005-02-08

The wording of the definition of 'term' needs to be improved. The current definition is:

The generic name for a property (i.e. element or element refinement), vocabulary encoding scheme, syntax encoding scheme or concept taken from a controlled vocabulary (concept space).

and the suggested improvement is as follows:

A property (i.e. element or element refinement), vocabulary encoding scheme, syntax encoding scheme or concept taken from a controlled vocabulary (concept space).

Note that "The generic name for" should probably be removed from the start of all of the current definitions in which it appears.

Usage of "Resource URI" and "Value URI"

Tom Baker, 2006-02-25

The DCAM terminology of Resource URI / Value URI feels slightly inconsistent:

_ Resource URI - doesn't say what kind of resource
Value _ URI - doesn't say it is a resource

Confusingly, a Value URI would seem to be a resource URI (in a general sense) but not a Resource URI (in a DCAM sense).

This could be corrected by consistently specifying

Subject Resource URI
Value Resource URI

Or, more concisely, by specifying

Subject URI
Value URI

Usage of "Resource"

Tom Baker, 2006-04-04

Related to the above, there is an entity labeled "Resource" in DCAM, Figure 4, but the definition offered in the Glossary is generic ("anything with identity"). The modeling entities Property and Value are "resources", but it doesn't really sound right to say "the Resource is a resource". Renaming "Resource" to "Subject" consistently in the DCAM would solve this problem (e.g., "the Subject is a resource").

Either that, or make it all very explicit by calling everything a resource, i.e.: Subject Resource, Property Resource, Value Resource.

"Is a URI"

Mikael Nilsson, 2005-04-29

I see the following texts in the DCAM:

"It should be noted that all the values that are encoded in this syntax are represented by value strings, even those that look, to the human reader, as though they are URIs."

"Again, it should be noted that the value of the DC Identifier property represented in this encoding syntax is denoted by a value string, even though it looks, to the human reader, as though it is a URI."

I now think this is a bit confusing. They *are* URIs. It should be said instead that they "do not fill the conceptual role of a value URI, even though they are URIs" or something to that effect.

DCAM and rich representations

Pete Johnston 2005-08-17

According to the DCAM, a statement in a DC description can contain a rich representation of a resource.

So that rich representation could be

a chunk of XML in any XML format or
a blob of binary data

Now I know you can encode binary data as text (base 64 encoding) so we can get our rich representation into XML and other text-based serialisation formats. That's fine.

But what the DCAM doesn't provide is a means of telling me what XML format that chunk of XML is an instance of, or what binary format I'm dealing with once I decode my base 64 stuff from text back to binary. (I think this works in XML applications only because the XML language dictates that that element content which is a base64 string is an encoding of a GIF, or whatever, so the knowledge is built in to the application?)

But in the wild, an application gets a hint about what to do with some unknown bitstream from a MIME type, right? So shouldn't the DCAM say that a rich representation is (or can be) associated with a MIME type?

I don't think this is a serialisation/binding issue - the base 64 encoding is a serialisation/binding issue, yes - but once an application has decoded the base64 string to get back to a binary blob, it needs to know what binary format that binary blob is in: the rich representation is useless without this. Strictly speaking I think the same applies for XML formats, but in that case I guess applications get hints from XML Namespace Names and root element names and so on....

Conforming to the DCAM

Various people, 2005-09-19

What does "conformance" mean for the DCAM? Is FOAF DCAM compliant? Are all RDF applications DCAM conformant?

There is a notion of conformance of single terms to the DCAM
There is a notion of conformance of *applications* to the DCAM - that is, that it treats properties/subproperties correctly (or at least sanely). I think a LOM application using DC properties included as LOM extensions would probably *not* be comforming, but most RDF applications would. There are probably levels of conformance ("supports only value strings", etc).
There is a notion of conformance of *syntaxes* to the DCAM, which is really similar to application conformance.
There is also a notion of "compatibility" of abstract models. I don't think this is the same as conformance. FOAF and RDF are compatible with the DCAM, LOM is not. Exactly what this means is unclear, of course. It could possibly mean that, for example, RDF applications and RDF vocabularies will automatically be conformant to the DCAM, thus delegating the definition of "compatibility" to be defined in terms of the "conformance" of the applications and vocabularies. Does this make sense or not???

SES and Language tags

Pete Johnston 2005-08-23

In RDF, plain (non-datatyped) literals can have a language tag; typed literals have a datatype but do not have a language tag

i.e. a literal can not have both a language tag and a datatype.

The DCAM currently says

Each value string may have an associated syntax encoding scheme URI that identifies a syntax encoding scheme.
Each value string may have an associated value string language that is an ISO language tag (e.g. en-GB).

i.e. it permits a value string to be associated with both a language tag and a syntax encoding scheme URI.

Should that be tightened up in the DCAM to say a value string may be associated with either a language tag or syntax encoding scheme URI, but not both?

Blank nodes

Does the DCAM support statements with no value URI and no value strings? Can such a value be used as subject of a related description? This would be similar to "blank nodes" in RDF.

Vocabulary encoding schemes and classes

Alistair Miles, 2005-10-10

I suggest that DCMI:

drops the notion of allowing a 'subject scheme' to also be a 'class of values',
drops the recommendation to use rdf:type to link a 'subject' to a 'subject scheme',

See [the list posting].

Missing definitions for "sub-property" and "sub-class"

Tom Baker, 2006-03-08

DCAM [1] uses "sub-property" as an adjective (e.g., "sub-property relationships").

In Section 2, seventh bullet point, "sub-property" is used as a noun ("the sub-property"), and it is part of Figure 1. However, nowhere is "sub-property" actually defined.

"Sub-class" is also not defined.

Possible solution: instead of defining these as nouns, rephrase text so that used only for relationships. Dan suggests looking at http://www.w3.org/TR/rdf-schema/#ch_subpropertyof .

See [the list posting].

Definition of Related Description

Tom Baker, 2006-03-28

A "related description" is really just another "description", albeit one that is seen from a certain standpoint.

A related description is a description of a resource that is related to the resource being described.

This is analogous to "sub-class" and "sub-property" being just "class" and "property" seen in a certain relationship. In such cases, one could perhaps remove them as named modeling entities and find ways to rephrase the text in order to emphasize the relationships between entities.

Domain and range

Pete Johnston, 2006-03-09

Given that there are suggestions for adding rdfs:domain/rdfs:range data to the descriptions of DCMI properties, should the concepts of property range and property domain be added to the DCAM?

(Editorial) Description of Purpose of DCAM

Pete Johnston, 2006-03-31

The sentence

The primary purpose of this document is to provide a reference model against which particular DC encoding guidelines can be compared.

might be interpreted as saying that DC encoding guidelines and the formats they describe can be be created/designed without reference to the DCAM and then compared with each other through the reference model of the DCAM. This does not reflect how the DCAM should be used in relation to DC encoding guidelines: the DCAM provides the basis for the design of DC encoding guidelines. The creators/designers of those guidelines and the formats they describe must use the DCAM as the starting point, not as something to be referenced/compared with afterwards.

Empty statements

Alistair Miles, 2006-05-04

Statement without either value strings, VES, rich descriptions or value URIs are not explicitly forbidden. Maybe they should be.

> AMIssues