RE: Moving forward with ISSUE-30 (IRI template expansion)

> -----Original Message-----
> From: Markus Lanthaler [mailto:markus.lanthaler@gmx.net]
> Sent: Tuesday, August 19, 2014 11:21 AM
> To: public-hydra@w3.org
> Subject: RE: Moving forward with ISSUE-30 (IRI template expansion)
> 
> On 19 Aug 2014 at 09:10, McBennett, Pat wrote:
> > Markus Lanthaler wrote on 15 Aug 2014 at 17:07:
> >> On 14 Aug 2014 at 23:28, McBennett, Pat wrote:
> >>>    [
> >>>      a IriTemplate ;
> >>>      template "http://example.com/users/{id}" ;
> >>>      variableExpansion hydra:SimplifiedTurtleExpansion ;
> >>>      mapping [
> >>>        a IriTemplateMapping ;
> >>>        variable "id" ;
> >>>        property ex:userId .
> >>>      ]
> >>>    ]
> >>> Or alternatively, 'hydra:ExpansionNone' and
> >>
> >> Honestly, I found this naming confusing at best. The *template* will
> always
> >> be expanded. Variables on the other hand, are not "expanded" in the
> >> same sense. Assuming the values of variables are RDF literals, we
> >> just include different components thereof. "NoExpansion" means we
> >> just use the lexical representation and ignore the datatype and the
> optional language tag.
> >> "SimplifiedTurtleExpansion" means we will use all components and
> serialize it
> >> in a Turtle-like syntax.
> >
> > That's an excellent point.
> >
> >> Taking that into consideration, could you live with calling the
> >> property "variableRepresentation"?
> >
> > Turtle (and by extension SimplifiedTurtle) is a language (i.e. the
> > 'Terse
> RDF Triple
> > Language'), and the W3C spec defines the syntax for that language,
> > which
> provides
> > 'compatibility with the N-Triples format'.
> >
> > Since we're trying here to describe: 'the syntax, format, or language
> > used for describing how to interpret the substitution values for all
> > variables used in this template mapping', how about:
> 
> Pat, we have endless alternatives but if we keep proposing new alternatives
> instead of discussing existing proposal, we won't make any progress. 

Ouch!

> Naming is hard. Not everyone will be happy with every decision we'll make.
> Standardization often means that the result will be something that makes
> everyone equally unhappy. 

I completely and utterly agree. That's *why* I was suggesting alternatives. In my experience with difficult naming decisions, having *more* alternatives on the table actually helps the discussion.

I was only offering new alternatives because my understanding of this particular issue was greatly improved by the very-much appreciated feedback I received (which only came from Markus). I genuinely apologize if I was confusing or diverting the discussion - that was never my intention.

> So, given, that everyone else involved in this
> discussion seems to be happy with "variableRepresentation" (please correct
> me if I'm wrong), I'll ask you again:
> 
> Could you live with calling the property "variableRepresentation"? If not, why
> not?
> 

It thought I had made it clear 'why not'. To repeat, I've found developers have difficulty with the 'abstractness' of the word 'representation'. I also asked the group 'is it just me?'. As you say, 'everyone else involved in this discussion seems happy' with that term (i.e. nobody has said otherwise) - so I guess it *is* just me.

So can I 'live' with it? Of course can I. I was simply trying to improve on it by offering alternatives I thought developers would be more comfortable with (I thought that was how 'discussion' generally worked). But I'm sorry if my contributions weren't helping - "variableRepresentation" it is...

> I know you personally don't like the term representation but I'm sure we can
> find some wording in the specification to describe appropriately what is
> meant by that term in this context.
> 

Ok.

> 
> Thanks,
> Markus
> 
> 
> --
> Markus Lanthaler
> @markuslanthaler
>

Received on Tuesday, 19 August 2014 22:12:05 UTC