W3C home > Mailing lists > Public > public-hydra@w3.org > January 2015

RE: Introduce VariableRepresentation class (ISSUE-80)

From: Markus Lanthaler <markus.lanthaler@gmx.net>
Date: Wed, 7 Jan 2015 00:50:46 +0100
To: "'Hydra'" <public-hydra@w3.org>
Message-ID: <050001d02a0b$98075a90$c8160fb0$@gmx.net>
On 6 Jan 2015 at 10:02, Ruben Verborgh wrote:
>> Actually, we try to avoid having a property and a class which differ only
>> their capitalization. Should we follow Schema.org's convention and name
>>   hydra:VariableRepresentationType
> I'd be fine with that.


>> instead of just
>>   hydra:VariableRepresentation
> Now that we're talking about naming: when documenting the properties,
> I've found "variable representation" to be confusing:
>     {
>       "@id": "hydra:VariableRepresentation",
>       "@type": "hydra:Class",
>       "subClassOf": "hydra:Resource",
>       "label": "representation of variable values",
>       "comment": "A representation specifies how to serialize variable
values into strings.",
>       "vs:term_status": "testing"
>     }
> So even though it is called *VariableRepresentation*
> it actually defines how *values* are represented.
> I can live with either name, and we have discussed this before,
> but I just wanted to point out my experience actually adding it to the

Hmm... good point. We didn't really discuss this, did we? As far as I
recall, we discussed ValueRepresentation as an alternative to
BasicRepresentation. Strictly speaking, this defines how the values of
variables are represented in an expanded templated. I don't like
VariableValueRepresentation at all. Saying something like "the value
representation of this IRI template is ..." makes it a bit difficult to
understand what is meant IMO. "The variable representation of this IRI
template is ..." sounds clearer to me. What if we just tweak the comment to

  A VariableRepresentation specifies how to serialize a variable's value to
a string.

Any other ideas?

Markus Lanthaler
Received on Tuesday, 6 January 2015 23:51:08 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 23:51:08 UTC