Although dcterms:subject recommends that values be taken from a 
controlled vocabulary, I think that some aspects of today's controlled 
vocabulary practices are carry-overs from pre-identifier practices in 
the string-based world of libraries. For someone outside of the that 
culture it may be suitable to use identifiers for real world objects as 
subject values -- people, places, chemical compounds. There's no reason 
for these to have the addition re-direction as SKOS concepts to be 
legitimate subjects of a resource.

I'm even beginning to question that we should recommend "controlled 
vocabulary" as more RWOs are defined with IRIs. Historical practice does 
not distinguish between concepts and RWOs, and therefore treats equally 
the concept "person" and actual persons ("Napoleon Bonapart"). Surely 
we'll move beyond that now that we have the capability to distinguish 
between them.

kc

On 8/15/15 5:46 AM, Jan Voskuil wrote:
> Hi Antoine, you are right. Maybe it would be just as powerful if the "official"  definition and description of use leaves range formally undefined while at the same time explicitly stating that values are expected to be instances of skos:Concept. On the other hand, this would do less in terms of pushing organizations into wrapping concepts around their lists of literals. And a formal range definition would still bear a " comply or explain"-character: you could still use resources that are not (explicitly) typed as skos:Concept. You are still free to ignore the possible type-transfer phenomena. -j
>
> -----Original Message-----
> From: DCMI Architecture Forum [mailto:[log in to unmask]] On Behalf Of Antoine Isaac
> Sent: vrijdag 14 augustus 2015 17:00
> To: [log in to unmask]
> Subject: Re: dcterms:type and SKOS
>
> Hi Jan,
>
> I agree.
> However, setting a formal range to skos:Concept may end up in having the same issues if, someone wants to use a resource of a different type than skos:Concept, which may be useful in some cases.
> Unless the DC terms adopts a model of a 'softer' type, as schema.org did, where the range rather indicates 'expected' than 'mandatory' types [1]
>
> Antoine
>
> [1] see e.g. https://schema.org/author . There must be somewhere online a discussion about this, but I lack the time to search for it...
>
>> Hi Antoine, thank you for your comments and the pointers.
>>
>> I completely agree on your point about string literals.
>>
>> But that is exactly why I would like to propose to declare skos:Concept as range of dcterms:type (and, frankly, as many other properties as possible; dcterms:subject would come to mind).
>>
>> The use of string literals is indeed pervasive. As an example, in the Netherlands we have an official standard called NTA 2084 Taxonomy of Document Types. It features concepts and narrowers, written in the traditional form (NT). The entire taxonomy is published in the form of a PDF-document. Organizations use the defined string literals as value of dcterms:type, referring to the DCAP for the Dutch public sector, OWMS. Everybody seems to think this is just fine.
>>
>> I feel it would be desirable to coax these organizations into publishing the taxonomy in terms of SKOS: this should be a breeze in terms of time and money and offers some concrete benefits. And the next step is of course use the concepts instead of string literals as value of dcterms:type. The general idea is that we should get rid of controlled vocabularies that concsist of string literals and use published skos:ConceptSchemes instead, which I honestly believe is one of the greatest visionary ideas behind SKOS.
>>
>> This is just one example. The point is: by convincing organization to wrap concepts around string literals, one would greatly stimulate the use of SKOS, create economy of scale, and hence, in the longer run, stimulate the use of Linked Data in general.
>>
>> So my line of thinking is more towards the promotion of SKOS than fixing formal semantics per se.... -j

-- 
Karen Coyle
[log in to unmask] http://kcoyle.net
m: 1-510-435-8234
skype: kcoylenet/+1-510-984-3600