RDF.ex v0.8.0 Release Notes
Release Date: 2020-06-01 // almost 4 years ago-
๐ RDF literals and their datatypes were completely redesigned to support derived XSD datatypes and ๐ allow for defining custom datatypes. โก๏ธ For an introduction on how literals work now read the updated page on literals in the guide. โฌ๏ธ For more details on how to migrate from an earlier version read this wiki page.
โ Added
- a lot of new datatypes like
xsd:float
,xsd:byte
orxsd:anyURI
-- all numeric XSD datatypes are now available; see this page of the API documentation for an up-to-date list of all supported and missing XSD datatypes - an implementation of XSD facet system now makes it easy to define own custom datatypes via restriction of the existing XSD datatypes
- โก๏ธ
RDF.Literal.update/2
updates the value of aRDF.Literal
without changing anything else, eg. the language or datatype
๐ Changed
- the
RDF.Literal
struct now consists entirely of a datatype-specific structs in theliteral
field, which besides being more memory-efficient (since literals no longer consist of all possible fields a literal might have), allows pattern matching now on the datatype of literals. - RDF XSD datatypes are now defined in the
RDF.XSD
namespace - alias constructor functions for the XSD datatypes are now defined on
RDF.XSD
matches?
,less_than?
,greater_than
as higher level functions were removed from theRDF.Literal.Datatype
modulesless_than?
,greater_than?
now always return a boolean and no longernil
when incomparable; you can still determine if two terms are comparable by checking ifcompare/2
returnsnil
- ๐ the
language
option is not supported on theRDF.XSD.String.new/2
constructor - the
language
option onRDF.Literal.new/2
is no longer ignored if it's empty (nil
or""
), so this either produces an invalidRDF.LangString
now or, if anotherdatatype
is provided will fail with anArgumentError
canonical
now performs implicit coercions when passed plain Elixir values- the inspect format for literals was changed and is now much more informative and uniform, since you now always see the value, the lexical form and if the literal is valid
RDF.Namespace.resolve_term/1
now returns ok or error tuples, but a new functionRDF.Namespace.resolve_term!/1
with the old behaviour was added- ๐ Elixir versions < 1.8 are no longer supported
๐ Fixed
- numeric operations on invalid numeric literals no longer fail, but return
nil
instead - Datetimes preserve the original lexical form of the timezone when casting from a date
- โ BEAM error warnings when trying to use top-level modules as vocabulary terms
- a lot of new datatypes like