Allowing variableRepresentation also on IriTemplateMapping (was: variable representations edited for spec)

>>> However, let's extend the interface with a structured free-text field:
>>>    ?subject / ?predicate / ?object / ?freeText
>>> where the ?freeText field allows control characters (*, ?, .).
>>> Then the first 3 are hydra:ExplicitRepresentation,
>>> and the 4th is ex:FreeTextWithControlChars.
>> 
>> Hmm... I'm not sure you need a separate representation format for that.
[...]

This is now being discussed in a separate thread


>> Apart from that, I do see some value in allowing different serializations
>> within a single IRI template... I'm just *a bit* worried about the
>> complexity and variability we introduce by that. Sure it might be able to
>> save a couple of characters in the resulting IRI, but that's about it.
> 
> Mmm, I wasn't thinking about the savings, but about functionality.

For me, this is in principle the same question as to what image format (JPG,
PNG, BMP, ...) you use. They all have their strengths and weaknesses but in
the end it doesn't change *that* much (I know about animated GIFs :-P). At
the moment we cover the two extremes: complete information
(ExplicitRepresentation ? BMP) and lossy compression (BasicRepresentation,
language and type-information lost ? JPG). What functionality do we enable
by allowing to mix the two? I completely agree that it would be nice to do
so in some cases but does it change anything apart from making the resulting
URLs longer/shorter?


>> It neither simplifies serialization nor deserialization. In any case, I
removed
>> variableRepresentation's domain to not prevent this in the future.
> 
> +1
> 
>>> It's not about this use case per se (even though I will implement it),
>>> but also to show that such use cases are actually quite common.
>> 
>> Another way to implement that would be to provide two IRI templates: one
>> with subject, predicate and object variables and the other one with just
the
>> freetext variable.. but of course you can't combine them in that case.
> 
> Yes, and yes :-)
> I don't want to complexify things, but we should be open to the extent
possible.

Absolutely. I just don't see how mixing representation formats helps clients
or servers or enables new functionality that can't be realized otherwise.


--
Markus Lanthaler
@markuslanthaler

Received on Wednesday, 31 December 2014 16:07:26 UTC