Open doriantaylor opened 1 year ago
So, to be clear, if you require rdf/reasoner
and do RDF::Reasoner.apply(:rdfs)
I can see that
RDF::Vocab::SKOS.prefLabel.entail(:subPropertyOf).map(&:pname) # => [ "rdfs:label", "skos:prefLabel" ]
But,
RDF::RDFS.label.entail(:subProperty).map(&:pname) # => [ "rdfs:label" ]
and you'd expect it to include everything that has a subPropertyOf relationship back to rdfs:label
?
I'll need to look into this, such entailments work for other vocabularies, as contained within the specs. It may be related to owl:imports
.
indeed:
[1] pry(main)> require 'linkeddata' # hauls in the relevant modules, of course
=> true
[2] pry(main)> RDF::Reasoner.apply :rdfs
=> [:rdfs]
[3] pry(main)> RDF::Vocab::RDFS.label
=> #<RDF::Vocabulary::Term:0x4cbbc ID:http://www.w3.org/2000/01/rdf-schema#label>
[4] pry(main)> RDF::Vocab::RDFS.label.subProperty
=> []
[5] pry(main)> RDF::Vocab::SKOS.prefLabel.subPropertyOf
=> [#<RDF::Vocabulary::Term:0x4cbbc ID:http://www.w3.org/2000/01/rdf-schema#label>]
that's with rdf
3.2.9, rdf-vocab
3.2.3, rdf-reasoner
0.8.0. Maybe the SKOS vocab indeed does not have an explicit owl:imports
RDFS?
Sorry to take so long to respond to this issue. If you look at the documentation for RDF::Reasoner::RDFS.subProperty, you'll see that it works within the vocabulary in which it is defined as well as vocabularies which import that vocabulary.
Get the immediate subproperties of this property.
This iterates over terms defined in the vocabulary of this term, as well as the vocabularies imported by this vocabulary.
So, for RDFS.label.subProperty to include SKOS.prefLabel, SKOS would need to do an owl:includes
or RDFS. This was done in order to contain the combinatorics of adding new vocabularies, so that it wouldn't need to traverse every defined vocabulary too look for all possible values. So, this behavior should be unchanged from previous versions.
Hey, just noticed that (after applying
RDF::Reasoner
),skos:prefLabel
/skos:altLabel
/skos:hiddenLabel
.subPropertyOf
points tordfs:label
but not the other other way around. Haven't looked at the code for a while so not sure why that would be the case.