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
________________________________________
Van: DCMI Architecture Forum <[log in to unmask]> namens Antoine Isaac <[log in to unmask]>
Verzonden: donderdag 13 augustus 2015 11:16
Aan: [log in to unmask]
Onderwerp: Re: dcterms:type and SKOS
Hi Jan, Simon,
This is indeed a problem from the perspective of dctersm:type, and the practioners who want to want to retained 'OWL-DL'ness.
From the SKOS perspective, there's indeed nothing formally wrong with having something declared (or infered) both as a skos:Concept and an rdfs:Class. Next to the pointers already exchanged I could also refer to
http://www.w3.org/TR/skos-primer/#secskosowl
http://www.sciencedirect.com/science/article/pii/S1570826813000176 (5th page)
So the questions are whether your case really needs DL-compatibility (many cases just don't need this).
And of course remains the one, whether dcterms:type has the best axiomatization possible.
I agree with you that the current axioms makes it too close to rdf:type.
Plus, reacting to your sentence below:
> The other problem is that as a result of this, people are hesitant to use skos:Concept as the value of this property.
>
I believe this has not prevented people to create statements using dcterms:type with simple strings (literals), which is even worse from a formal perspective.
(note: I personally don't care so much about creating such statements, especially after I'm told to use the stricter dcterms: namespace rather than the good old flexible dc11: namespace)
Best,
Antoine
On 8/13/15 6:41 AM, Simon J D Cox wrote:
> Hi Jan -
>
> Ok - I think I understand a bit better. The issue is not so much the SKOS meta-modelling capability, but the formal definition of dcterms:type. As you point out, if
>
> dcterms:type rdfs:range rdfs:Class .
>
> then it is rather too similar to rdf:type!
>
> In the RDF universe, rdf:type is a special predicate, being the only one that is routinely used to cross meta-levels, relating instances to types (classes). The formal semantics of dcterms:type appears to duplicate rdf:type, and precludes the use of a skos:Concept as its value because of the risk of breaking DL semantics.
>
> Simon
>
> ------------------------------
>
> Date: Wed, 12 Aug 2015 06:05:21 +0000
> From: Jan Voskuil <[log in to unmask]>
> Subject: Re: DC-ARCHITECTURE Digest - 10 Aug 2015 to 11 Aug 2015 (#2015-26)
>
> Hello Simon,
> The problem you are referring to is related to but slightly different from the dcterms:type-issue.
> I agree that a given skos:Concept often "refers to" or "is about" something that may be thought of as a class or set.
>
> Note that "refers to" here is used not in the rdf-semantics sense of the word. The notion of aboutness causes instances of skos:Concept to function as a kind of metamodeling-vocabulary.
>
> In my current project we use instances of skos:Concept to make "first class modeling concepts" in our vocabularies easily accessible and findable. To do this, we use foaf:focus to relate the concept in the thesaurus to the class, property or individual in our ontology. Example:
>
> ex:OrganisationConcept a skos:Concept ;
> foaf:focus rov:RegisteredOrganisation.
>
> Interesting literature on this is [1], [2] and [3].
>
> Note, however, that in the above example individuals and classes are strictly separated. The construction satisfies strict DL-constraints. One problem with dcterms:type is that it introduces punning and is (to some undefined degree) synonymous to rdf:type, independently of the metamodeling-features of SKOS. The other problem is that as a result of this, people are hesitant to use skos:Concept as the value of this property. -Jan
>
> [1] http://xmlns.com/foaf/spec/#term_focus
> [2] “Getty Vocabularies: Linked Open Data Semantic Representation”, chapter 3 “Concept vs Thing Duality”, http://vocab.getty.edu/doc/#Concept_vs_Thing_Duality.
> [3] Pete Johnston, “Things & their conceptualisations: SKOS, foaf:focus & modelling choices”, http://efoundations.typepad.com/efoundations/2011/09/things-their-conceptualisations-skos-foaffocus-modelling-choices.html
>
>
> ________________________________________
> Van: DCMI Architecture Forum <[log in to unmask]> namens Simon J D Cox <[log in to unmask]>
> Verzonden: woensdag 12 augustus 2015 01:23
> Aan: [log in to unmask]
> Onderwerp: Re: DC-ARCHITECTURE Digest - 10 Aug 2015 to 11 Aug 2015 (#2015-26)
>
> Dear Jan -
> This is actually a well-known problem/feature (depending on your pov) in SKOS.
> SKOS Concepts are often 'classes' in the generic sense, but the SKOS RDF vocabulary makes them instances.
> SKOS is really a bridging vocabulary to help move traditional 'vocabularies' into RDF, but stops short of modelling them fully as classes.
> Your reference to 'punning' is on point. Don't expect DL compliance.
>
> Simon Cox
>
>
> Simon J D Cox
> Research Scientist
> Environmental Information Infrastructures Land and Water CSIRO
>
> E [log in to unmask] T +61 3 9545 2365 M +61 403 302 672 Until 2015-09-06:
> 37 Graham Road, Highett, Vic 3190
> PO Box 56, Highett, Vic 3190
> From 2015-09-07:
> Bayview Avenue, Clayton, Vic 3168
> Private Bag 10, Clayton South, Vic 3169 people.csiro.au/C/S/Simon-Cox
> orcid.org/0000-0002-3884-3420
> researchgate.net/profile/Simon_Cox3
>
> PLEASE NOTE
> The information contained in this email may be confidential or privileged. Any unauthorised use or disclosure is prohibited. If you have received this email in error, please delete it immediately and notify the sender by return email. Thank you. To the extent permitted by law, CSIRO does not represent, warrant and/or guarantee that the integrity of this communication has been maintained or that the communication is free of errors, virus, interception or interference.
>
> Please consider the environment before printing this email.
>
>
> -----------------------------
>
> Date: Tue, 11 Aug 2015 16:55:54 +0100
> From: Jan Voskuil <[log in to unmask]>
> Subject: dcterms:type and SKOS (retried)
>
> Dear all,
> In recent work I have struck on a problematic interaction between SKOS and DC. These standards should strengthen each other. Using SKOS to publish value lists and then to use the skos:Concepts therein as the value of, for instance, dcterms:subject, offers significant benefits. However, there is a problem with dcterms:type, because it is declared with rdfs:Class as its range. This complicates the use of instances of skos:Concept as its value.
>
|