DaniFdezAlvarez / shexer

Apache License 2.0
26 stars 2 forks source link

IRI instead of shape #143

Closed jjkoehorst closed 11 months ago

jjkoehorst commented 1 year ago

I am seeing the IRI more often than I think it would be needed... for example

jerm:hasPart IRI ; # 100.0 %

100.0 % obj: @:Assay. Cardinality: {1}

        # 100.0 % obj: @:Q739897-Assay. Cardinality: {1}

Shows that both objects which have a shape on its own should be part of the IRI either with an OR or AND

but also for example in assignedTaxon which only have a Taxon object associated to it states that this is only the case in 20%?

gbol:assignedTaxon IRI ; # 100.0 %

20.0 % obj: @:Taxon. Cardinality: {1}

I am not sure what is happening here.

DaniFdezAlvarez commented 1 year ago

Regarding the first issue: if I got it well, you can get a constraint such as jerm:hasPart @Assay OR @Q739897. Short answer: set disable_or_statements=False when building the Shaper object. Long answer: check this conversation with @andrawaag on how this works: https://github.com/DaniFdezAlvarez/shexer/issues/121

Regarding the second issue: that kind of output indicates that 1/5 of the instances of the shape you are extracting have exactly one relation with an object of type Taxon. The other 4/5 instances has exactly one relation with an object, but the type of that object is unknown (not Taxon though), or it is known but it is not associated with an extracted shape. Then sheXer uses IRI in the actual constraint, as the macro subsumes Taxon and whatever type the other objects could be.

At least, that is how it should work. Does this explanation fit your data?