Skip to content

Upgrading to RDF.ex 1.0

Marcel Otto edited this page Nov 3, 2022 · 1 revision

Although the RDF.Vocabulary.Namespaces were rewritten completely there are almost no breaking changes, so migration should be quite straightforward.

Changes on vocabulary namespaces

The only breaking change is that passing multiple objects as separate arguments to the property functions of the description DSL on the vocabulary namespaces are no longer support to create space for further arguments for other purposes in the future. So, multiple objects in a property function like this:

EX.S 
|> EX.p(1, 2, 3)

must be given now in a list instead:

EX.S 
|> EX.p([1, 2, 3])

However, one of the new features leads to a new best practice for defining vocabulary namespaces with aliases. Instead of repeating the aliases of directly specified terms in an alias definition, the aliases can now be provided directly in the list of terms. So, something like this:

defmodule YourApp.NS do
  use RDF.Vocabulary.Namespace

  defvocab EX,
    base_iri: "http://www.example.com/ns/",
    terms: ["Foo-bar", "Baz"],
    alias: [FooBar: "Foo-bar"]
end

can now be written like this:

defmodule YourApp.NS do
  use RDF.Vocabulary.Namespace

  defvocab EX,
    base_iri: "http://www.example.com/ns/",
    terms: [
      :Baz,
      FooBar: "Foo-bar"
    ]
end

But there are more new capabilities which might simplify vocabulary namespace definitions. Please read the extended introduction of vocabulary namespaces for more.

Just one more thing. If you ever wanted to use other expressions in a defvocab definition than plain literals, this is supported now. So, you can write now something like this.

defmodule YourApp.NS do
  use RDF.Vocabulary.Namespace

  defvocab EX,
    base_iri: M.ns() <> "/foo",
    terms: [:bar]
end

Changes on RDF graph builder

RDF.Graph.build/2 blocks are now wrapped in a function, so the aliases and import no longer affect the caller context. aliases in the caller context are still available in the build block, but imports not and must be reimported in the build block. Variables in the caller context are also no longer available in the build block, but must be passed explicitly as bindings in a keyword list on the new optional first argument of RDF.Graph.build/3.

use RDF # this can be used now to get most of the most important imports and aliases
alias EX
import Something

var = "foo"

# we need to pass var as binding to be able to use it in the build block
RDF.Graph.build var: var do
  # Something is not imported here and needs to be re-imported again to be available
  import Something

  # EX is available  
  {EX.S, something(), var}
end

Other breaking changes

Some modules were renamed for consistency reasons:

  • RDF.BlankNode.Increment was renamed to RDF.BlankNode.Generator.Increment
  • RDF.XSD.Datatype.Mismatch exception was renamed to RDF.XSD.Datatype.MismatchError