Use dcam:domainIncludes and dcam:rangeIncludes

[coolharsh55]

Currently, DPV leaves its properties without a domain or range to enable use where relevant even if we know there are specific intended concepts. To indicate what we know as the possible domain and range concepts, we should use dcam:domainIncludes and dcam:rangeIncludes with these concepts so that there is some guidance on where a given property is applicable. DCMI defines these concepts as a suggested class - so there is no strictness involved or inference/reasoning implications.

[pmcb55]

Yep, I think this is very good.
I started using schema:range/domainIncludes ages ago, but then switched over to gist:range/domainIncludes (as gist is a far better 'fit' for our real world modelng needs than Schema.org).
But I'd never even heard of DCAM before, so I may consider switching again now to dcam:range/domainIncludes (since we used dcterms: a lot already, but it's just such a shame that these two terms aren't in the 'main' DCTERMS vocab, and are instead kinda hidden in this DCAM vocab - d'oh!).

[TallTed]

I fully support using dcam:range/domainIncludes as "more correct", but I suggest also including schema:range/domainIncludes (introduced circa 2013, based on the first archive.org capture), as more tools will understand these, even now, 3 years after introduction of the dcam:, (2020-01-20, 8 years after the previous DCMI Metadata Terms version), because schema:range/domainIncludes originated well before dcam:range/domainIncludes.

The gist: prefix appears to once have meant https://ontologies.semanticarts.com/gist#, but that no longer appears to exist on the web, and even the WebArchive doesn't seem to contain any versions of gist:rangeIncludes or gist:domainIncludes (I confess, I haven't clicked to see every capture, but the WebArchive's "changes" interface is entirely empty), so I find it difficult to see how it could be a better fit than anything that can be tracked to an actual ontological definition!

[coolharsh55]

Hi. I'm open to using schema:range/domainIncludes. Though a question arises as to what extent do schema.org concepts should be used here? There's also schema:Property and so on for the vocabulary metadata, and also for the taxonomies themselves e.g. Data types - and what are the implications of these? So far, I have avoided using schema.org in favour of using the 'usual' sem-web standards (RDFS, DCT, etc.) as it is sufficient to describe the work.

[TallTed]

In some arenas, people use schema.org preferentially, because Google's crawlers and indexers do a better job with it than with some niche ontologies. In others, the niche ontologies are different enough from schema.org and important enough to the content that people avoid schema.org and use other (S)SEO methods. Moderately good reasoners shouldn't care which you use, if you've included relations (a bridge ontology) between your niche ontology/ies and such "general purpose" ontologies as schema.org.

All that said — my argument for including the schema:rangeIncludes/schema:domainIncludes predicates — which I would expect to have the same values as the dcam:rangeIncludes/dcam:domainIncludes predicates — is strictly about the adoption levels of these ontologies. Including both in your data lowers the barriers others may have to working with your data, as neither you nor they have to run live reasoners in query processors nor data loaders; all the relations are just there and queries just work.

[coolharsh55]

So we just include schema:range/domainIncludes - correct? I'm okay with that. I'm refactoring the code currently - so I'll implement it right away.

[pmcb55]

Hiya @TallTed - yeah, the gist community switched their namespace IRI to use the w3id.org PURL service (to avoid the 'lock-in' associated with the domain semanticarts.com, which is the domain of the relatively small consultancy company that created gist in the first place, see issue here). So the new namespace IRI is now: https://w3id.org/semanticarts/ns/ontology/gist/ (and just to note, gist is strongly suggested as an example of a good starting point in this blog piece from Oracle - I think that's where I first came across it myself).

And so, although they don't (yet!) provide a HTML page per ontology term, the gist:domainIncludes term is defined here.

And just by the way, but I've no issue with DPV including schema:range/domainIncludes alongside/as-well-as the DCAM predicates - as you say, adoption levels alone justify it I think.

(And also, just to be clear, I'm not suggesting that DPV should use the gist:range/domainIncludes terms either - it's just that gist in general is a better fit than Schema.org for our real-world modeling use-cases.)