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

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.

Regards,
Ryan Riley

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