W3C home > Mailing lists > Public > public-dxwg-wg@w3.org > August 2018

Re: [dxwg] Use of dct:type with both Class and Concept

From: kcoyle via GitHub <sysbot+gh@w3.org>
Date: Tue, 28 Aug 2018 18:04:55 +0000
To: public-dxwg-wg@w3.org
Message-ID: <issue_comment.created-416684768-1535479494-sysbot+gh@w3.org>
I've finally gotten my head around this (sorry it took so long). The problem as I see it is not in dct nor in DCAT, but in the fact that some communities are still using controlled term lists rather than classes to "classify" types. These are generally carry-overs from older metadata practices that had no concept of "class". A loosening of dct:type could make a choice like this more "valid":
        dct:type	<http://purl.org/dc/dcmitype/Text> ;
	dct:type	<http://id.loc.gov/vocabulary/marcgt/man> ;
	dct:type	<http://registry.it.csiro.au/def/datacite/resourceType/Text> ;
	dct:type	<http://registry.it.csiro.au/def/re3data/contentType/doc> ;

but I don't think that is the main issue here. The question that I see, instead, is whether there is a negative to be found in declaring something like http://id.loc.gov/vocabulary/marcgt/man to be a class when it is used in that way. To me, it serves the same conceptual role as a class and re-casting it as a class is taking it in the direction in which it should go when used in RDF. 

I do not think it would be better to have two properties -
- dct:type for types that are defined as classes
- dcat:(someName) for types that are defined as instances

And I don't see a way to have a single property that has a range of both classes and instances unless defined as an annotation property, which has no advantages whatsoever, AFAIK. 

My other comment is that although terms lists like those at id.loc.gov already exist, unless one intends to use a significant number of the terms it may be best to define ones' own list of classes, with some links to related classes or terms from other environments. I don't know if there is an analysis of the types that are likely to be useful to DCAT, but my gut feeling is that few of the id.loc.gov content types[1], carrier types[2] or media types[3] will be appropriate, so adding these to the DCAT mix may cause more problems than they solve. These lists and others like them *should* be replaced by RDF-appropriate classes as their communities move to the use of RDF (although I would not place bets on that happening in my lifetime). 

My vote would be: don't use lists from outdated metadata practices; do the right thing and create RDF-appropriate classes.

[1] http://id.loc.gov/vocabulary/contentTypes.html
[2] http://id.loc.gov/vocabulary/carriers.html
[3] http://id.loc.gov/vocabulary/mediaTypes.html

-- 
GitHub Notification of comment by kcoyle
Please view or discuss this issue at https://github.com/w3c/dxwg/issues/314#issuecomment-416684768 using your GitHub account
Received on Tuesday, 28 August 2018 18:05:11 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 30 October 2019 00:15:45 UTC