Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

prefixes of XML attributes are not resolved #322

Closed
mielvds opened this issue Dec 14, 2022 · 3 comments
Closed

prefixes of XML attributes are not resolved #322

mielvds opened this issue Dec 14, 2022 · 3 comments

Comments

@mielvds
Copy link

mielvds commented Dec 14, 2022

Hi there! SPARQL-Anything tries to reuse the XML namespaces as much as possible. However, it seems that this only the case for elements; attributes are turned into literals. Isn't that unintuitive?

Example:

  • input: <premis:premis xsi:type="premis:intellectualEntity">
  • output: [] a premis:premis; xsi:type "premis:intellectualEntity"
  • expected: [] a premis:premis; xsi:type premis:intellectualEntity
@enridaga
Copy link
Member

Hi Miel! I see your point. The issue is that we cannot make assumptions about attribute values in XML without inspecting the schema, so the safe way is to consider them as literals.
If the XML is bound with a Schema and we support XSD schema resolution, it could be possible to know that a given attribute value is supposed to be a QName, but it would still be problematic to generalise (any string is an IRI anyway, colons don't make it safe to distinguish prefixed vs non-prefixed URIs).
This is a typical issue with XML; see, for example, https://stackoverflow.com/a/50236609/1035608 .

The safer thing is to handle these cases in your mappings (I guess you will transform the data anyway). If you still want an IRI from that string, you can always BIND( fx:entity ( "premis:intellectualEntity") as ?type ) assuming premis: is in the set of ns declarations.

My two cents

@mielvds
Copy link
Author

mielvds commented Dec 14, 2022

That makes total sense. Thanks @enridaga !

@mielvds mielvds closed this as completed Dec 14, 2022
@mielvds
Copy link
Author

mielvds commented Dec 14, 2022

btw, I would suggest adding a summary of your answer to the docs where it says "SPARQL Anything reuses namespaces declared ..."

enridaga added a commit that referenced this issue Dec 15, 2022
enridaga added a commit that referenced this issue Dec 20, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants