AGENDA - Usage Board telecon
2006-10-27 Friday - 1300 UTC, 1500 Berlin, 0600 Seattle, 2200 Tokyo
Participants: Akira, Andrew, Andy, Diane, Joe, Stuart, Tom (chair)
Regrets: Stuart
Guest: Pete
1. Definition of dc:type
The current definition of dc:type [1] is:
The nature or genre of the content of the resource.
The definition proposed for public comment [2] is:
The genre, functional category, or aggregation level of
the resource.
Pete has raised some basic questions regarding the use of
dc:type in the DCAM (see summary below).
Resolution of this issue is on the critical path to
finalizing the DCMES changes. We have scheduled a telecon
about this for next Friday, but I hope we can already
largely work this out on the list. I have summarized the
discussion below.
For discussion: Could we simply revert to the original
definition (minus "the content of"):
The nature or genre of the resource.
2. AOB
----------------------------------------------------------------------
Summary of discussion
In the draft Domains and Ranges Vocabulary [3], Andy suggests a
range for Type of ResourceType, defined as:
A genre, functional category, or aggregation level.
Pete has raised some issues with regard to the proposed
definition [4 and below], specifically:
-- DCAM says that "Each resource may be a member of one or
more classes"; this is a key aspect of the DC resource model.
-- In the current DC-RDF draft [5], statements using dc:type
are mapped to RDF triples using rdf:type. The earlier
DCQ-RDF draft [6] describes rdf:type as a subproperty
of dc:type, clearly indicating the intent to include the
instance-class relationship.
-- The word "nature" in the original definition captured this
intended is-instance-of relation -- implementers see the
"world" according to the classes of resources to be described.
-- The proposed definition actually narrows the semantics
of dc:type (red flag: DCMI Namespace Policy) and does not
adequately reflect real world use of the dc:type property.
Pete recommends that the proposed definition _not_ be
accepted. Rather, the definition should make clear that the
instance-class relationship _is_ intended -- "has genre",
"has functional category" and "has aggregation-level" are
just three specific examples of such relationships.
He feels that if we go with the proposed definition,
instance-class relationships would not be representable using
dc:type, so the DCAM would either need to be extended with
something an additional construct (ResourceClassURI?) --
or a property other than dc:type would need to be used.
[1] http://dublincore.org/documents/dcmi-terms/
[2] http://dublincore.org/usage/public-comment/2006/08/dcmes-changes/
[3] http://dublincore.org/usageboardwiki/PropertyDomainsAndRanges
[4] http://www.jiscmail.ac.uk/cgi-bin/webadmin?A2=ind0610&L=dc-usage&P=53
[5] http://dublincore.org/documents/dc-rdf/
[6] http://dublincore.org/documents/dcq-rdf-xml/
----------------------------------------------------------------------
From: http://dublincore.org/usage/public-comment/2006/08/dcmes-changes/
> 2.2. Type
>
> The definition of Type as "The nature or genre of
> the content of the resource" was found to be
> unhelpfully vague. As with Format, words from the
> original comment were used to formulate the definition:
> "The genre, functional category, or aggregation level
> of the resource.
>
> The Usage Board will be particularly interested
> to hear of implementations of Type that do not fit
> into the scope of "genres, functional categories,
> or aggregation levels".
[...]
> URI: http://purl.org/dc/elements/1.1/type
>
> OLD> Documented at: http://dublincore.org/documents/2005/06/13/dcmi-terms/#type
>
> OLD> Label: Resource Type
> OLD> Definition: The nature or genre of the content of the resource.
> OLD> Comment: Type includes terms describing general categories,
> OLD> functions, genres, or aggregation levels for
> OLD> content. Recommended best practice is to select a
> OLD> value from a controlled vocabulary (for example,
> OLD> the DCMI Type Vocabulary [DCMITYPE]). To describe
> OLD> the physical or digital manifestation of the
> OLD> resource, use the Format element.
>
> NEW> Documented at: http://dublincore.org/usage/public-comment/2006/08/dcmes-changes/#type
> NEW> Documented at: http://dublincore.org/usageboard/2006/2006-06.dcmes/dcmes-changes/#type
>
> NEW> Label: Type
> NEW> Definition: The genre, functional category, or aggregation level
> NEW> of the resource.
> NEW> Comment: Recommended best practice is to use a controlled
> NEW> vocabulary such as the the DCMI Type Vocabulary
> NEW> [DCMITYPE]). To describe the file format, physical
> NEW> medium, or dimensions of the resource, use the
> NEW> Format element.
>
> Changes proposed:
> -- In label, changed "Resource Type" to "Type" [see Section 1.6]
> -- In definition, replaces "content of the resource" with "resource"
> [see Section 1.1]
> -- In comment, replaces "use a value from an encoding scheme" with "use an
> encoding scheme" [see Section 1.3]
> -- In comment, replaces the phrase "use a value from a controlled
> vocabulary" with "use a controlled vocabulary" [see Section 1.4]
> -- Definition reworded for concreteness [see Section 2.2]
----------------------------------------------------------------------
From: Pete's posting of October 4, http://www.jiscmail.ac.uk/cgi-bin/webadmin?A2=ind0610&L=dc-usage&P=53
> However the DCMI Abstract Model notes that
>
> > Each resource may be a member of one or more classes.
>
> i.e. the is-instance-of relation is a core part of the DC resource
> model. And further
>
> > In DCMI metadata descriptions, the class of the resource being
> > described is normally indicated by the value of the DC Type property
>
> In the current DC-RDF draft, statements made using the dc:type property
> are mapped to RDF triples using an rdf:type predicate. Admittedly it
> does not say that all rdf:type predicates should be mapped to statements
> using the dc:type property but if that is not the case then the mapping
> is one-way (though I suspect it is already for other reasons).
>
> I note also that the earlier DCQ-RDF draft describes rdf:type as a
> subproperty of dc:type, clearly indicating the intent that the dc:type
> property did include the instance-class relationship.
>
> The inclusion of "nature" in the original definition is important. The
> is-instance-of relation is a core part of the DC resource model.
> Metadata implementers work on the basis of domain model in which they
> partition the resources in their "world" according to their "nature"
> (e.g. they decide to model their application domain as a set of
> Documents, Concepts and Agents, etc with specific types of relationship
> between instances of those classes). How they decide what classes they
> require is an application-specific consideration, determined by their
> functional requirements. If it is useful for them to have a class of
> Blue Things, then they can, and according to the DCAM, the dc:type
> property is used to represent the instance-class relationship.
>
> I am concerned that the proposal represents a narrowing of the dc:type
> property which contradicts an existing DCMI Recommendation and does not
> adequately reflect real world use of the dc:type property, and I think
> the revised definition should not be accepted. If anything, as the
> object of this exercise was "to bring their language into line with that
> of the DCMI Abstract Model", it should be made clearer in the definition
> that the dc:type property _is_ - as the DCAM says - used to represent
> the instance-class relationship, and that "has genre", "has functional
> category" and "has aggregation-level" are just three specific examples
> of relationships which are usefully modelled as instance-class
> relationships
>
> Alternatively, if the intent is that dc:type is not usable to represent
> the instance-class relationship in the general case then this
> information can not be captured using a property of the DCMES (or the
> "Simple DC" application profile). I recognise that we are shifting away
> from the emphasis on the DCMES, but still, this seems a very serious
> limitation to impose. But if that is what is intended then
>
> (a) the statement in the DCAM is wrong
> (b) given that the instance-class is a core part of the resource model
> (and we are placing emphasis on the importance of application/domain
> models based on that resource model) then we should indicate how this
> information is to be captured in DC descriptions
>
> To do (b), we could either
>
> - add (yet another) construct to the description model (ResourceClassURI
> or whatever). I am getting worried that the description model is already
> becoming too complex, with the separation of VES and valueClass, though
> I'm also conscious that having a Value Class construct without a
> ResourceClass may be perceived as odd; or
>
> - (as at present) specify a property (other than dc:type) to be used in
> a statement to represent the is-instnce-of relationship
----------------------------------------------------------------------
Mikael reply to Pete, citing
http://dublincore.org/architecturewiki/DCRDFTaskforce/PublicCommentJune2006
> Proposals
>
> * Recommmend the use of rdf:type in RDF metadata, together with an
> explanation that it is equivalent to dc:type for a DC
> application.
>
> * Revisit this issue after the introduction of domains and ranges
> of DCMI properties, to make sure the semantics really match.