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

1.6: Adopt Turtle grammar for IRIs, CURIEs, literals #133

Open
cmungall opened this issue Dec 22, 2022 · 1 comment
Open

1.6: Adopt Turtle grammar for IRIs, CURIEs, literals #133

cmungall opened this issue Dec 22, 2022 · 1 comment
Labels
1.6 spec proposals concrete proposals for changes in 1.6

Comments

@cmungall
Copy link
Member

cmungall commented Dec 22, 2022

From @balhoff:

  • <http://purl.obolibrary.org/obo/UBERON_1234567> could be used anywhere that UBERON:1234567 can be used
  • Strings are always quoted
  • People may not like this everywhere, like the value for term names
  • No need to guess what is a full IRI and what is an abbreviated IRI (CURIE)
  • Solve current problems with IRI mangling
  • Solve questions about language tags support

From @cmungall:

  • I think making strings always quoted is a major breaking change; against
  • I don't think the <> quoting is necessary
@cmungall cmungall added the 1.6 spec proposals concrete proposals for changes in 1.6 label Dec 22, 2022
@althonos
Copy link
Member

@cmungall : You don't need the <> quoting provided you change the rules for xref lists and qualifier lists (#148); otherwise, since , and = are valid IRI characters, every construction of the form [iri, iri, iri] or {iri="value"} is ambiguous.

Keeping IRIs non escaped could work if you require all identifier to be followed by at least a whitespace: then you would have to change the lists to be [ iri , iri , iri ] which looks a bit ugly but makes sure the IRI are terminated properly.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
1.6 spec proposals concrete proposals for changes in 1.6
Projects
None yet
Development

No branches or pull requests

2 participants