Referring to the Turtle/OWL for AltR here:
Is it really best practice to be adding restrictions, or even a skos:scopeNote meta-data, to an already existing term from another vocabulary - specifically rdfs:Resource (I assume there's a typo there now)? If I load this T-box data into my existing triplestore, then it'll infer that skos:scopeNote applies to all instances of rdfs:Resource I may have already in my dataset, which wouldn't be correct.
Should you not be sub-classing rdfs:Resource and adding your scope-specific restrictions and meta-data to that sub-classed term? E.g., something like:
altr:Resource
rdfs:subClassOf rdfs:Resource ;
a owl:Class ;
rdfs:label "Resource" ;
skos:definition "The class resource, everything."@en ;
rdfs:subClassOf [
a owl:Restriction ;
owl:onProperty altr:hasRepresentation ;
owl:allValuesFrom altr:Representation
] ;
dct:source "http://www.w3.org/2000/01/rdf-schema#Resource" ;
skos:scopeNote "In the context of this mode, rdf:Resource instances are
used to identify Internet resources, that is items
identified by a URI." .
I notice the existing issue here suggests dropping the restriction, but the same issue applies to skos:scopeNode.
And the issue applies to dct:conformsTo and dct:Standard too.
Referring to the Turtle/OWL for AltR here: Is it really best practice to be adding restrictions, or even a
skos:scopeNote
meta-data, to an already existing term from another vocabulary - specificallyrdfs:Resource
(I assume there's a typo there now)? If I load this T-box data into my existing triplestore, then it'll infer thatskos:scopeNote
applies to all instances ofrdfs:Resource
I may have already in my dataset, which wouldn't be correct.Should you not be sub-classing
rdfs:Resource
and adding your scope-specific restrictions and meta-data to that sub-classed term? E.g., something like:I notice the existing issue here suggests dropping the restriction, but the same issue applies to
skos:scopeNode
.And the issue applies to
dct:conformsTo
anddct:Standard
too.