Warning:
This wiki has been archived and is now read-only.

Feature:CreatingIrisAndLiterals

From SPARQL Working Group
(Redirected from Feature:IriBuiltIn)
Jump to: navigation, search


Feature: Built-In Functions to create IRIs and literals

If CONSTRUCT supports expressions in construction patterns then it should be possible to create names of things, i.e. IRIs and literals of all sorts.

Feature description

  • STR() gets an IRI or a literal and returns the string. The proposed IRI() gets a string or other literal and returns IRI.
  • An operator, such as X@Y, should return a literal whose string value is equal to string value of X and lauguage tag is equal to string value of Y.
  • An operator, such as X^^Y, should return a literal whose string value is equal to string value of X and type is equal to IRI value of Y.

IRI() Built-In

If CONSTRUCT supports expressions in construction patterns then it should be possible to create names of things. IRI() can be convenient in FILTERs as well, but FILTER (IRI(?x) = ?y) can be replaced with FILTER (isIRI(?y) and (str(?x) = str(?y)) whereas CONSTRUCT makes the feature next to unavoidable.

  • IRI(unbound) gives unbound.
  • IRI(string) gives either IRI or of unbound is unbound.
  • IRI(anything else) uses STR() in order to cast the argument to the above mentioned case.
  • Hence, IRI(iri) returns its argument unchanged.

It is not obvious what to do with ill formed IRI strings passed as arguments. They may result errors at the time of IRI() call or errors at the time of storing or transmitting ill formed IRIs (if they're not dropped by filtering or LIMIT or simply not used in the final result set) or the garbage may go out and rejected (or even accepted) by the client.

Creating typed literal

If CONSTRUCT supports expressions in construction patterns then it should be possible to create literals of all sorts. X^^Y can be convenient in FILTERs as well, but FILTER (SAMETERM(X^^Y,Z)) can be replaced with FILTER (isLITERAL (Z) and (STR(X)=STR(Y)) and (DATATYPE(X)=DATATYPE(Y)) whereas CONSTRUCT makes the feature next to unavoidable.

Two semantics are possible for X ^^ unbound, if X is typed literal. It may either return untyped variant of X ("remove the type") or return X as is ("no type -- nothing to do"). Two semantics are also possible if X is a literal with language or a node. Assuming that X ^^ Y tends to work like str(X) ^^ Y, it may either return X as is ("no type -- nothing to do") or work like str(X) ^^ unbound. Thus if we should choose the simplest possible semantics, we can make rule "X ^^ unbound returns X" unconditional and of highest priority.

Creating literal with language

If CONSTRUCT supports expressions in construction patterns then it should be possible to create literals of all sorts. X@Y can be convenient in FILTERs as well, but FILTER (SAMETERM(X@Y,Z)) can be replaced with FILTER (isLITERAL (Z) and (STR(X)=STR(Y)) and (LANG(X)=LANG(Y)) whereas CONSTRUCT makes the feature next to unavoidable.

Examples

Composing ordered list of items from a query that produce list nodes, indexes of items and valeus of items.

CONSTRUCT { ?list `iri(bif:concat(str(rdf:_), str(?n)))` ?nthvalue } ...
CONSTRUCT { 
  ?ferment <agent>
      `(?protein-sequence-string ^^ ?serialization-type )`
  } ...
CONSTRUCT { 
  ?component <gui-menu-item>
      `bif:concat (?local-title, " (", ?local-brief-description, ")") @ LANG(?local-title))`
  } ...

Existing Implementation(s)

  • Virtuoso implements IRI() and will support X^^Y and X@Y as soon as syntax of these features is confirmed by a draft of the spec.

Existing Specification / Documentation

List any existing text that attempts a formal definition of this extension. This could be a draft specification, API or syntax documentation, etc.

Compatibility

New keyword guarantees that IRI() is a "pure extensions".

In order to ensure the compatibility, the ^^ and the @ operators should have the priority one less than unary minus, so -5^^<mm> and - (space) 5 ^^ <mm> should both result in "-5"^^<mm>, not a value in former and unary minus operator applied to "5"^^<mm> in the latter case. Similarly, -5@"en" and - (space) 5 @ "en" should both result in "-5"@en, not a value in former and unary minus operator applied to "5"@en in the latter case.

For biggest possible compatibility, a new built-in functions can be introduced, not operators. Nevertheless, there should be something.

Links to postponed Issues

Related Features

Champions

Use cases

A description of one or more use cases, the solution of which requires this feature. Multiple use cases can be added to each feature.

References