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

Hi Ryan,

Welcome on the list (and sorry for not getting back to you earlier... I'm
pretty bad with keeping up with mails when I'm traveling).

On 24 Jul 2014 at 06:57, Ryan Riley wrote:
> On Jul 21, 2014, at 2:31 PM, Ruben Verborgh 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

That's great. I'm very interested to see how this might look like in a
functional language.


> 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.

Please keep us posted on your progress and let us know if you run into any
problems. If things are unclear, please don't hesitate to ask. The current
spec leaves much to be desired.


> 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.

Sure. The point I was trying to make though was that if it is a boolean, you
just need *one* check. In case of IRIs you need *at least two*. A boolean
also reduces errors (typos) and makes it clear that this is not an extension
point. We seem to disagree whether this should be extensible or not. I'd
prefer to keep it simple by just having two ways to expand an IRI template
value. This increases interoperability but prevents "innovation".


> 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.

Yep, that's a feature, not a bug IMO :-) It improves interoperability. I
don't see much value in having dozens of ways to serialize values. Thus I
proposed this pragmatic solution to allow exactly two ways: the simplest
possible serialization (no types, languages tags etc.) and the most precise
(all types, languages tags etc.)


> 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 think it is important to keep in mind that tools can use whatever
representation they want internally. The main question is: do we want this
to be an extension point or not? I'll send out a separate mail to discuss
that.


--
Markus Lanthaler
@markuslanthaler

Received on Saturday, 26 July 2014 02:22:13 UTC