Understanding Optional Dereferencing in RDF Ontologies

·Mar 24, 2024 08:20 PM

Why is it optional in RDF to provide a dereferencable ontology that can be processed by an RDF processor? One such example is XMLSchema (i.e. XSD). Here is what chatgpt says (which may or may not be accurate) "In summary, while dereferencing namespace URIs to ontologies or vocabulary definitions is a common and recommended practice in RDF, it is not strictly required by the RDF specifications. Namespaces primarily serve to provide unique identifiers for terms and vocabularies, and the decision to dereference them to ontologies or provide documentation is up to the creators and users of the RDF data."

7 comments

· Sorted by Oldest

Holger K.
·
That's also because many if not most use cases of RDF are in closed (enterprise) applications, where exposing data to the outside is not even desirable. The Semantic Web vision was just one possible use case of RDF, which is a general graph data model.
👍3
Andrew P.
·
I see but in case i described above (xsd) its very much public and a core dependency for other ontologies. I suppose the answer is a dereferenceable IRI is not required and the semantics behind such IRIs are tacit rather than explicit ?
Holger K.
·
I cannot comment on whether the RDF vocabulary itself is dereferencable, if that’s what you mean. But most tools that I know about have some built-in knowledge about how the core of RDF (and related languages) work. For example, the use of rdf:type and rdfs:subClassOf is typically hard-coded into some algorithms.
👍1
Holger K.
·
In the case of SHACL, the vocabulary is machine readable on the web and most features attempt to describe themselves there.
👍1
Andrew P.
·
yes those make sense to me (i.e. rdf:type) to just be understood because they are fundamental elements in rdf ( atomic?) maybe i should think of xsd datatypes in the same way ? just seems intuitive to me that everything should be machine readable / accessible. I don’t know if xsd is a singular outlier or there are other ontologies not dereferenceable and therefore not defined at least as a machine readable vocabulary.
Holger K.
·
What we do in our product is that we include a dedicated “systems” graph that is always there and which defines, for example, that xsd:string is an rdfs:Datatype. This means we are decoupled from external graphs for things that are essential for the functioning of our product. Sure, for example, our user interface forms are completely model-driven and have very little hard-coded, except how to look up property definitions and datatypes.
💯2
Phil T.
·
Having written more than a couple of validating processors over the years, you learn the hard way that connectivity is unreliable, even in local environments. As Holger indicates, you want to decouple essential dependencies where the connectivity or performance will suffer. In the products I have built, I usually made the deref optional (user-discretion) depending on the level of validation required, and provided local fallback for mandatory dependencies such as xsd.
👍2

Holger K.
·
That's also because many if not most use cases of RDF are in closed (enterprise) applications, where exposing data to the outside is not even desirable. The Semantic Web vision was just one possible use case of RDF, which is a general graph data model.
👍3
Andrew P.
·
I see but in case i described above (xsd) its very much public and a core dependency for other ontologies. I suppose the answer is a dereferenceable IRI is not required and the semantics behind such IRIs are tacit rather than explicit ?
Holger K.
·
I cannot comment on whether the RDF vocabulary itself is dereferencable, if that’s what you mean. But most tools that I know about have some built-in knowledge about how the core of RDF (and related languages) work. For example, the use of rdf:type and rdfs:subClassOf is typically hard-coded into some algorithms.
👍1
Holger K.
·
In the case of SHACL, the vocabulary is machine readable on the web and most features attempt to describe themselves there.
👍1
Andrew P.
·
yes those make sense to me (i.e. rdf:type) to just be understood because they are fundamental elements in rdf ( atomic?) maybe i should think of xsd datatypes in the same way ? just seems intuitive to me that everything should be machine readable / accessible. I don’t know if xsd is a singular outlier or there are other ontologies not dereferenceable and therefore not defined at least as a machine readable vocabulary.
Holger K.
·
What we do in our product is that we include a dedicated “systems” graph that is always there and which defines, for example, that xsd:string is an rdfs:Datatype. This means we are decoupled from external graphs for things that are essential for the functioning of our product. Sure, for example, our user interface forms are completely model-driven and have very little hard-coded, except how to look up property definitions and datatypes.
💯2
Phil T.
·
Having written more than a couple of validating processors over the years, you learn the hard way that connectivity is unreliable, even in local environments. As Holger indicates, you want to decouple essential dependencies where the connectivity or performance will suffer. In the products I have built, I usually made the deref optional (user-discretion) depending on the level of validation required, and provided local fallback for mandatory dependencies such as xsd.
👍2