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

Literals with language tag support in DOSDP templates #494

Open
OliverHex opened this issue Jun 11, 2024 · 3 comments
Open

Literals with language tag support in DOSDP templates #494

OliverHex opened this issue Jun 11, 2024 · 3 comments

Comments

@OliverHex
Copy link

OliverHex commented Jun 11, 2024

Hi, is there a way to generate literals with language tags by using DOSDP ?

This is what I need in the resulting OWL file :

  • language-tagged literals such as "[LABEL]"@en
  • or datatyped language-tagged literals such as "[LABEL]"@en^^rdf:langString
    where [LABEL] is replaced by an actual label.

The first option is a syntactic sugar for the second, the second being the correct syntax according to the RDF standard, see "3.3 Literals" here : https://www.w3.org/TR/rdf11-concepts/#section-Graph-Literal

I have been doing a few tests with DOSDP templates.
The best I could obtain (but still wrong) is with the following template snippet :

name:
text: '"%s"@my_language_tag'
vars:
- myNameVar

Which generates the following literal for the rdfs:label annotation :

AnnotationAssertion(rdfs:label <http://www.test.org/my/TEST_0000001> "\"Some Random Name\"@my_language_tag"^^xsd:string)

Which is wrong since it integrates the language tag as part of the literal string.

Any solution for this, please ?

@dosumis
Copy link

dosumis commented Jun 12, 2024

Hi @OliverHex - AFAIK we don't support this, but we certainly should!

We could support the format you suggest above (or something very similar, we need to be careful about escapes on quotes). Implementation is in DOSDP-tools only, which scans for @ after quoted string. Not change is required to JSON schema except an update to the docstring. It feels very slightly hacky as it makes it impossible to include a quote followed by an @ in any string, but I think that's fine.

The only alternative I can think of involve having text take either a string or an object with string plus language tag. That object will need two keys (value and tag?)

@balhoff @hkir-dev do you have a preferred solution?

@balhoff
Copy link
Member

balhoff commented Jun 12, 2024

@matentzn I think your idea of another field for lang is appealing! Else we might need to include quotes within the actual parsed string values (but we could probably make that work also).

@OliverHex
Copy link
Author

Yes indeed the quotes and inner-quotes (with the @) in the text field could be tricky.
The additional tag field seems perfect.
Thank you for taking time on this issue !

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

3 participants