- 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