- From: Markus Lanthaler <markus.lanthaler@gmx.net>
- Date: Wed, 7 Jan 2015 00:50:46 +0100
- To: "'Hydra'" <public-hydra@w3.org>
On 6 Jan 2015 at 10:02, Ruben Verborgh wrote:
>> Actually, we try to avoid having a property and a class which differ only
in
>> their capitalization. Should we follow Schema.org's convention and name
this
>>
>> hydra:VariableRepresentationType
>
> I'd be fine with that.
Great
>> 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
voc.
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
@markuslanthaler
Received on Tuesday, 6 January 2015 23:51:08 UTC