Current Limitations and Proposed Solution

Oct 13, 2025 by talynt.org 90 views

Current Limitations and Proposed Solution

The current implementation of the rdf-imports filter definition in TOML files has a limitation where it only works with prefixes. This is due to the logic in the expand_curie function, which only expands prefixes and not pure URLs. To address this issue, we propose a solution that allows defining URIs in TOML files using the <> syntax, similar to Turtle syntax.

Understanding the Current Implementation

The rdf-imports filter definition in TOML files relies on the expand_curie function to expand prefixes and resolve URIs. However, this function only works with prefixes and not pure URLs. This limitation is due to the following code snippet in the apis_core/utils/rdf.py file:

def expand_curie(curie):
    """
    Expand a CURIE into a full URI.
    
    :param curie: A CURIE (e.g., "http://example.org/term")
    :return: The expanded URI (e.g., "http://example.org/term")
    """
    if curie.startswith("http"):
        return curie
    else:
        return f"http://{curie}"

As shown in the code snippet above, the expand_curie function checks if the input CURIE starts with "http" and returns it as is if it does. Otherwise, it prefixes the CURIE with "http://" and returns the result. This implementation only works with prefixes and not pure URLs.

Proposed Solution: Supporting Pure URLs in TOML Files

To address the limitation of the current implementation, we propose a solution that allows defining URIs in TOML files using the <> syntax, similar to Turtle syntax. This would enable support for pure URLs in the rdf-imports filter definition.

Here's an example of how the proposed solution could be implemented:

[rdf-imports]
filter = [
  {
    "predicate": "<http://test.at/predicate>",
    "subject": "<http://test.at/subject>",
    "object": "http://test.at/object"
  }
]

In this example, the predicate and subject fields are defined using the <> syntax, which allows them to be treated as pure URLs. The object field is defined as a plain URL without the <> syntax.

Benefits of the Proposed Solution

The proposed solution has several benefits:

Improved flexibility: By allowing pure URLs in TOML files, the rdf-imports filter definition becomes more flexible and easier to use.
Better support for Turtle syntax: The proposed solution aligns with the Turtle syntax, which is widely used in RDF data.
Easier maintenance: With the proposed solution, developers can define URIs in TOML files using a syntax that is familiar to them, making maintenance easier.

Implementation Details

To implement the proposed solution, the following changes would be required:

Update the expand_curie function: The expand_curie function would need to be updated to handle the <> syntax and treat the input as a pure URL.
Add support for the <> syntax in TOML files: The TOML parser would need to be updated to recognize the <> syntax and treat it as a valid way to define URIs.
Update the rdf-imports filter definition: The rdf-imports filter definition would need to be updated to support the <> syntax and allow pure URLs.

Conclusion

Q: What is the current limitation of the `rdf-imports` filter definition in TOML files?

A: The current implementation of the rdf-imports filter definition in TOML files only works with prefixes. This is due to the logic in the expand_curie function, which only expands prefixes and not pure URLs.

Q: Why is the `expand_curie` function limited to only expanding prefixes?

A: The expand_curie function is limited to only expanding prefixes because of the following code snippet in the apis_core/utils/rdf.py file:

def expand_curie(curie):
    """
    Expand a CURIE into a full URI.
    
    :param curie: A CURIE (e.g., "http://example.org/term")
    :return: The expanded URI (e.g., "http://example.org/term")
    """
    if curie.startswith("http"):
        return curie
    else:
        return f"http://{curie}"

Q: What is the proposed solution to address the limitation of the `rdf-imports` filter definition in TOML files?

A: The proposed solution is to allow defining URIs in TOML files using the <> syntax, similar to Turtle syntax. This would enable support for pure URLs in the rdf-imports filter definition.

Q: How would the proposed solution be implemented?

A: To implement the proposed solution, the following changes would be required:

Update the expand_curie function: The expand_curie function would need to be updated to handle the <> syntax and treat the input as a pure URL.
Add support for the <> syntax in TOML files: The TOML parser would need to be updated to recognize the <> syntax and treat it as a valid way to define URIs.
Update the rdf-imports filter definition: The rdf-imports filter definition would need to be updated to support the <> syntax and allow pure URLs.

Q: What are the benefits of the proposed solution?

A: The proposed solution has several benefits:

Improved flexibility: By allowing pure URLs in TOML files, the rdf-imports filter definition becomes more flexible and easier to use.
Better support for Turtle syntax: The proposed solution aligns with the Turtle syntax, which is widely used in RDF data.
Easier maintenance: With the proposed solution, developers can define URIs in TOML files using a syntax that is familiar to them, making maintenance easier.

Q: How would the proposed solution affect existing code?

A: The proposed solution would require updates to existing code that uses the rdf-imports filter definition in TOML files. Specifically, developers would need to update their code to use the <> syntax to define URIs.

Q: What is the expected timeline for implementing the proposed solution?

A: The expected timeline for implementing the proposed solution is not yet determined. However, it is expected to be a multi-step process that involves updating the expand_curie function, adding support for the <> syntax in TOML files, and updating the rdf-imports filter definition.

Q: Who would be responsible for implementing the proposed solution?

A: The implementation of the proposed solution would be the responsibility of the development team that maintains the apis-core-rdf library.