Join GitHub today
GitHub is home to over 50 million developers working together to host and review code, manage projects, and build software together.Sign up
Expansion of IRI templates should be better documented #30
How should a client pass the value in the template?
And then again, which maker are we talking about?
How can it translate this data into an actual HTTP request?
As I mentioned in an email reply, I think this can be unambiguous:
URI encoded, un-quoted value is a URI or BNode (although the use of a BNode vs. just unspecified ids dubious in a triple pattern.
URI encoded, un-quoted value is a could be a compact IRI/PName. It can be distinguished from an absolute IRI if the string prefix matches a prefix name defined either as an RDFa @Prefix (or default prefix from the initial context) or a prefix defined in a JSON-LD context supplied to the client, or a prefix defined in some alternative RDF serialization supplied using content-negotiation. However, this has marginal value, and is probably not necessary as a general case.
URI encoded, quoted value is a string literal, which would probably match any literal having that lexical value
Relative URI? Probably not necessary, but it can be determined using straight-forward IRI matching rules.
URI encoded, quoted value with language tag is a language-tagged literal
Alternatively, specify language as another query parameter.
@gkellogg Concerning “unambiguous”, not that my current reason for including angular brackets
So I think if we decide to support both prefixes names and IRIs (and we should at least support the latter), there should be some explicit mechanism to distinguish between them. Or we can just not support prefixed names; no harm done there.
My server currently handles this as follows:
But I'd rather not have this last step in the spec;
The prefix/IRI issue is exactly that faced by RDFa, so I think the solution can be the same. Also, if a matching prefix is defined, it's a compact IRI, otherwise, it's a scheme-based IRI. The use of angle brackets is Turtle/sparql specific, and not really developer friendly for this use case, IMO.
PROPOSAL: By default, when expanding a IRI template, use only the lexical representation of the value or the IRI (no quoting). Add a flag
Thus, the following values in Turtle notation expand to the following
How about adding a
RESOLVED: Introduce a new property
The difference between the two variable representation formats is illustrated by the following examples.
- Removed second example as they only differed in the property used - Add variableRepresentation to the example - Converted the description of BasicRepresentation and ExplicitRepresentation from a definition list to a simple paragraph to be consistent with the rest of the document - Moved warning up - Added an exemplary IRI Template to the example comparing the two representation formats This addresses #30.
…tation to the context ... and minor tweaks to their description. This addresses #30
- Add variable representations to Core Vocabulary. - Append regular template example before free text. - When introducing the concept of template variables, it's more instructive to show the regular case first. Also, this will make the explanation of representations more clear. - Explain variable representations. - Add representation examples. - Warn about ExplicitRepresentation versus Turtle. This addresses #30