2

I'm trying to make a knowledge graph of sorts with some of my company's data. I'm primarily using SKOS as the ontology for describing things, but I'm running into a quandry about the usage of ConceptSchemes.

Basically I want to create a concept scheme for navigating various concept schemes. Although SKOS asserts Concepts and Schemes to be disjoint, it also explicitly says skos:inScheme has no domain. This leads me to think I can get away with having a ConceptScheme where most/all of its concepts are actually ConceptSchemes.

This making Schemes navigable seems like it has to be a common enough problem, but I haven't been able to find much on the subject. Is this "Schemes of Schemes" an advisable approach? Or if not, is there a better way to link disparate concept schemes so that they get the navigability that such a solution would offer?

p.s. I tagged this with 'dcat' as well since I plan to build a DCAT data catalog (potentially a catalog of catalogs) in a similar way. However I think a clear answer to the main question should clear up the DCAT side of things too.

unor
  • 92,415
  • 26
  • 211
  • 360
Xedni
  • 3,662
  • 2
  • 16
  • 27
  • so does it related to my problem that if concept A is child of concept B and concept C both but I have to keep only one relation (A is narrower term for B) and have to take another class A' where (A' is a narrower term for B and A' is used for A)? – Talk is Cheap Show me Code Apr 24 '20 at 09:15

2 Answers2

2

Well, the specification is clear, Concept and ConceptScheme are disjoint. The domain of inScheme is irrelevant to this. “I know my actions are breaking rule A, but they are not breaking rule B, therefore it is okay to break rule A.” It doesn’t work that way.

So, what are the consequences of breaking the rule?

  • Data validators that know the SKOS rules would likely complain
  • Tools for editing or displaying SKOS will likely get confused and might not work
  • People familiar with SKOS will give you dirty looks when you describe your modelling

If you are okay with that (and you might well be) then go ahead.

cygri
  • 9,412
  • 1
  • 25
  • 47
  • The idea of RDF and OWL is the create self-describing data sets, independent from applications. However, the formal implementation of SKOS does not cover the full specification. For example, there shouldn't be more than one `skos:prefLabel`, the standard says, yet this can't be implemented because in OWL annotation properties cannot be `owl:FuntionalProperty`. If one day there is a SKOS specification in SHACL, for example, that ambiguity can be avoided and data validators could use the standards and the data logic, not their local application logic. – Ivo Velitchkov Apr 04 '19 at 06:21
  • So assuming I'd like to avoid using the ontology incorrectly, is there another way to go about this sort of recursive KOS I seem to be falling towards? Perhaps the assumption of skos was that a Concept Scheme will remain pretty much static over time. But I forsee *lots* of of independent schemes being produced (a. la AAA), and a need to integrate where those schemes lie on a larger knowledge graph. If a concept scheme is the end-all-be-all highest level thing you can have in skos, suddenly those schemes start to feel incredibly unwieldy. – Xedni Apr 04 '19 at 08:45
  • I don't understand why you want to use SKOS to relate the concept schemes. SKOS is primarily about broader/narrower/related relationships between concepts. Are these the kinds of relationships you want to express between concept schemes? What does it mean for a *scheme* to be broader/narrower than another? – cygri Apr 04 '19 at 10:07
  • @cygri (thanks for all your reponses btw). It's quite possible I'm completely botching what a Concept Scheme should be, and what it can be. Id say a scheme could have hierarchical relationships. Imagine I wrote an app, and I create a ConceptScheme for all the terms it uses. Separately, I have a `Services`. My app is is a service, so would probably be navigable from the `Services` scheme, but then it's behaving like a Concept. If I need to abandon the SKOS model for this portion, that's acceptable too, but it would be a shame since I'd need to build someting that looks an awful lot like skos. – Xedni Apr 04 '19 at 14:19
  • The other thing I'll mention is I'm a bit hung up on using skos because the `dcat` stuff also uses concepts and schemes as it's means of classifying stuff. – Xedni Apr 04 '19 at 14:22
  • ...and what's the reason you want to use *only* SKOS. I've only rarely found something productively used relying only on one ontology. Even importing (or partially re-using, which I woudln't recommend) less than three is rare. – Ivo Velitchkov Apr 04 '19 at 17:08
  • 1
    I wouldn’t model an app as a concept scheme. I might have a scheme “MyApp terms” with the terms used in the app. And then a “terminology” triple that links the app to the concept scheme. If I had a “Services” scheme, with a concept “MyApp” under it, then I would probably still want the concept to be a separate resource from the app itself. So I would have a resource of type skos:Concept called “MyApp”, and another resource of type xyz:Application called “MyApp”, linked by a property such as “main item”. Concepts have their own identity and lifecycle separate from the thing(s) they stand for. – cygri Apr 04 '19 at 19:13
  • @IvoVelitchkov I'm not only using skos, it's just the only part relevant to my question. Can you guys give me some examples of GOOD concept schemes if apps are bad choices? Ideally something in IT since it's hard to draw parallels between what I do and the handful of examples on the internet which are basically the Dewey Decimal system and the phylogenetic tree. – Xedni Apr 05 '19 at 01:06
1

There is no need to violate the disjointness of concepts and concepts schemes. If you use inScheme to create a scheme of schemes, or even a scheme M that is a mixed collection of schemes and concepts, you have not assigned two types to anything. Your scheme's members simply have different types. I agree with your interpretation that the lack of a domain for inScheme is intended to make this kind of thing possible.

To put it differently: There is a difference between assigning types Concept and Concept Scheme to the same resource (not allowed), and creating a collection that contains distinct members of both of these types.

PS. Whether this modelling approach is the best way to solve your problem, well, that's a different question from the one you asked here.

alexis
  • 48,685
  • 16
  • 101
  • 161