Introduce VariableRepresentation class (was: variable representations edited for spec)

On 30 Dez 2014 at 16:52, Ruben Verborgh wrote:
> Hi Markus,
> 
>> I really like this summary (and fully agree with it). Maybe we should put
it
>> somewhere.. at least in the Wiki for the time being till we find a better
place.
> 
> I've put it here for now:
https://www.w3.org/community/hydra/wiki/Guiding_Principles
> Linked from the start page. Feel free to change the title if too
ambitious.

That's perfect, thanks.


>> What I meant was that knowing that
>> 
>>  - BasicRepresentation is a VariableRepresentation
>>  - ExplicitRepresentation is a VariableRepresentation
>>  - *all* values of variableRepresentation are VariableRepresenations
>>
>> doesn't change much in practice. How would you leverage that knowledge?

You shouldn't have omitted the sentence that followed this:

    About the only thing I can think of is to query for
VariableRepresentation.

:-)

> Suppose we have a GUI to build Hydra templates.
> The knowledge that MyXyz is a VariableRepresentation
> would allow the GUI to offer it as possible value for
variableRepresentation.

Anything else?


>> Maybe... but much more interesting would be
>> to know how to use those (newly found) representation formats. We can't
>> describe that at the moment. Thus I see limited value in introducing such
a
>> superclass and a range.
> 
> How about "I don't understand representation X, so I'm trying Y instead".

Not sure I follow...


> Knowing that it's a representation helps.
> It can be inferred from the fact that it's used as object of
variableRepresentation;
> but what exactly can we infer if there is no name for it? :-)

Nothing.. as you said, machines are dumb. Humans might be able to infer
something from the name (URL) or by reading the natural language definition
they get by dereferencing the URL... which reminds me that we should add a
pointer from the concepts definition to the relevant section in the spec
(rdfs:seeAlso?).


>>> This case is likely too specific to put into the Core Vocabulary, but
>>> by defining a hydra:VariableRepresentation, I can explicitly tell a
>>> machine that this thing is a variable representation and it is thus
>>> able to interpret how it can be used (cfr. my remark about
>>> explicitness above).
>> 
>> Are you really able "to interpret *how* it can be used"?
> 
> *how* as in: can be used when a representation is expected,
> such as in the GUI example above.

IMO it just tells you one place *where* it can be used.


>> You have to be aware though that more than
>> likely no Hydra client will be able to make use of it since it hasn't
been
>> programmed to serialize values according to that representation format.
The
>> best it can thus do is to fail with a clear error message what went
wrong.
> 
> Exactly-and that's not a bad thing
> 
> I don't perceive it as added complexity;
> rather, it's defining a name for things that otherwise exist explicitly.
> If you're not interested in extending Hydra, you don't need to know.

When I spoke about increased complexity, I was talking about allowing
variableRepresentation on both IriTemplate and IriTemplateMapping. I think
it's time to split this discussion into different threads.. I'll do so now
:-)



--
Markus Lanthaler
@markuslanthaler

Received on Wednesday, 31 December 2014 15:38:14 UTC