W3C home > Mailing lists > Public > public-hydra@w3.org > July 2014

Re: Call for consensus on defining IRI template expansion (ISSUE-30)

From: Ryan Riley <ryan.riley@panesofglass.org>
Date: Thu, 24 Jul 2014 08:57:56 -0500
Message-ID: <BLU436-SMTP182E7E9F7E16FF2BFB48406E5FF0@phx.gbl>
CC: Markus Lanthaler <markus.lanthaler@gmx.net>, public-hydra@w3.org
To: Ruben Verborgh <ruben.verborgh@ugent.be>

On Jul 21, 2014, at 2:31 PM, Ruben Verborgh <ruben.verborgh@ugent.be> wrote:

>>>>   _:x hydra:valueRepresentation hydra:ExpandedRepresentation.
>>>> with
>>>>   _:x hydra:valueRepresentation hydra:ValueRepresentation.
>>>> being the default.
>> I could live with that if we can justify that increased complexity.
> Note that it's not necessarily more complex;
> with a boolean flag, you have to check whether the argument is true or false.
> Here, you have to check whether it's ExpandedRepresentation or ValueRepresentation.
> Simple string matching in both cases.

Apologies if this comment is out-of-context. Iíve been following the list for a week and am working through the ramifications of generating Hydra server and client code from F#. Iím actually using some parts of JSON-LD and Hydra in an upcoming version of a shipping product. In a future release, I want to fully comply with both; at the moment, Iím loosely following the idea.

With that context in mind, Iíd like to point out that Rubenís point of this as a string match holds in untyped or languages with weak type systems. I think it important to consider that, for some language bindings, the Hydra structure could be modeled as an abstract syntax tree and used by consumers through pattern matching. Using the model above provides a richer base for developing a correct and complete model of the semantics while also providing an opportunity for later expansion. A boolean does little to describe the semantics and locks you into two options.

Following the thought of a richer, semantic model, in F# I would model these alternatives as a sum type, similar to:

    type HydraValueRepresentation<íT> =
        | ExpandedRepresentation of íT
        | ValueRepresentation of ĎT

I could then use pattern matching, rather than string comparison, to detect what to do next:

    match representation with
    | ExpandedRepresentation x -> // handle expanded representation
    | ValueRepresentation x -> // handle value representation

íT is some generic type parameter. This example does not consider the complete semantics. This holds for other ML languages, Haskell, Scala, etc. Itís true that we could build the same model for a boolean value. However, I think the explicit expressivity of the strings provides better clarity.

Ryan Riley
Received on Thursday, 24 July 2014 13:58:28 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:29:42 UTC