New features proposed in issues implemented in the ontology

kg-construct / rml-core

RML-Core: Main features for RDF generation with RML

https://w3id.org/rml/core/spec

Creative Commons Attribution 4.0 International

12 stars 9 forks source link

New features proposed in issues implemented in the ontology #136

Closed anaigmo closed 2 months ago

anaigmo commented 2 months ago

This PR includes new features in the ontology and related documentation, solving the following issues:

#120: Should DatatypeMap be defined as a TermMap?
#72 add rml:UnsafeIRI and rml:UnsafeURI to ontology, shapes and spec
#50 add rml:URI to ontology, shapes and spec
#30 add rml:baseIRI property to ontology, shapes and spec
#51 Move rml:Strategyand rml:strategy to RML-CC
#51 Inconsistency due to rdfs:domain of rml:logicalTarget and its use on rml:LanguageMap

anaigmo commented 2 months ago

Updated files according to @pmaria 's review in last commit

dachafra commented 2 months ago

ok, let's wait until his final approval to merge it (@pmaria), thanks @anaigmo

anaigmo commented 2 months ago

Oki, now that definition is fixed :)

chrdebru commented 1 month ago

I looked at @anaigmo and @pmaria's work in the spec and shapes. I just want to confirm, unlike @dachafra's proposal of "pushing it further", rml:baseIRI's domain is triples maps, right?

Also, do we keep base IRIs as input in the configuration (overwritten by rml:baseIRI) when present, or do we assume that baseIRIs must be provided. The former is more flexible. The latter will require us to change all the test cases and examples in our specifications. Happy to work on rml:baseIRI test cases in the case of the former (testing failures, testing overwrites, ...).

pmaria commented 1 month ago

I looked at @anaigmo and @pmaria's work in the spec and shapes. I just want to confirm, unlike @dachafra's proposal of "pushing it further", rml:baseIRI's domain is triples maps, right?

Yest that is how I understood it, and how it is defined in the ontology now.

Also, do we keep base IRIs as input in the configuration (overwritten by rml:baseIRI) when present, or do we assume that baseIRIs must be provided. The former is more flexible. The latter will require us to change all the test cases and examples in our specifications. Happy to work on rml:baseIRI test cases in the case of the former (testing failures, testing overwrites, ...).

Yes, the former would be my preference as well. I think we should also explicitly define a default in the spec for if no baseIRI is provided via configuration.