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

> -----Original Message-----
> From: Markus Lanthaler [mailto:markus.lanthaler@gmx.net]
> Sent: Monday, August 11, 2014 3:57 PM
> To: public-hydra@w3.org
> Subject: RE: Moving forward with ISSUE-30 (IRI template expansion)
> 
> On 10 Aug 2014 at 17:53, McBennett, Pat wrote:
> > Markus Lanthaler wrote on 8 Aug 2014 at 11:07:
> >> 1) Do we want the new property to be called
> >>   a) expansionMechanism,
> >>   b) variableExpansion, or
> >>   c) variableRespresentation?
> >> I opt for variableRepresentation as it sounds most declarative and
> >> also indicates that this affects only the representation of the
> >> variables in
> the
> >> template, nothing else.
> >
> > a) I agree with Ruben's original point of 'expansionMechanism' being
> > 'a bit heavy'.
> > b) I kinda like 'variableExpansion', but are we really only ever
> > talking about variables being expanded here? I thought the whole point
> > of having an extensible approach was to allow new, not-yet-foreseen,
> > forms of 'transformation' beyond just basic variable substitution - i.e.
> > couldn't some new mechanism also want to encode 'special characters'
> > found in the literal? In that sense, 'transformation' might be broader
> > than 'expansion', but I feel it's a bit too heavy too.
> > c) Personally, I don't like the use of 'Representation' in general.
> > It's just so vague (unless you're a die-hard RESTafarian), and I've
> > found developers struggle with its 'abstractness'.
> 
> Really? In this particular case I find it the term that is probably most easily
> understood. All this property does, is to define how variables are represented
> when a IRI template is expanded.
> 

Ok, so maybe it is just me and my experience then. (Although I would say that any time I've told people that REST stands for 'REpresentational State Stransfer', the first question I get is 'what do you mean by 'representational?' :) ).

> It describes, e.g., how the variable id in the template /users/{id} is
> represented in the resulting IRI. You are right, transformation is broader, but
> we don't want to transform the value (think e.g. uppercase it), we just want
> to serialize it somehow to a string that can be used instead of that
> placeholder. So, variableSerialization could work too but it sounds a bit too
> "heavy" for my taste.
> 

Ok, so from the above it seems you really are only interested in variable expansion here, and nothing else. If someone did want to introduce a mechanism for uppercasing the entire URI (for whatever reason), they couldn't simply define their own 'variable representation' mechanism here, since it's purely for variable substitution. If they wanted to just uppercase the expanded variable values though, then this would be the correct mechanism for them to use.

Likewise, if someone wanted to do some custom encoding of part of the template URI other than the variables, then again, this would not be the correct mechanism to use for that.

Personally I preferred the broader interpretation that this mechanism could do 'anything' with 'any part' of the template URI, including variable substitution, character encoding, uppercasing(!), whatever. So am I correct that we really wish to limit this to purely variable substitution?

> 
> > So how about some more options:
> > d) expansionType
> 
> Could work but Type is too generic here and might be confused with
> rdf:type/or a literals datatype.
> 
> > e) expansionScheme
> 
> Could be confused with the IRI's scheme (http, https).
> 
> 
> > f) expansionMethod  (my preference now)
> 
> Could live with that but I would prefer a more declarative term..
> 
> 
> > f) expansionApproach
> > f) expansionStrategy
> 
> Sounds way too complex to me.
> 
> 
> >> 2) What do we call the expanded value representation (mechanism
> >> described in [2])?
> >>   a) ExpandedRepresentation
> >>   b) CompleteRepresentation
> >>   c) something else?
> >> I'm leaning towards b) but am open for better names.
> 
> Ruben said
> 
> On 8 Aug 2014 at 14:31, Ruben Verborgh wrote:
> > The main characteristic about this option is that it explicitly
> > differentiates between URIs and literals, and between literals of
> > specific types and languages.
> >
> > How about ExplicitRepresentation?
> > That seems a bit more precise than "Complete".
> 
> I completely agree.
> 
> 
> > I assume you mean 'what do we call the output of the expansion
> > mechanism described in [2]'? Where are you looking to use this new
> > term (i.e. is it just in the prose of the spec, or are you trying to
> > name a new Hydra property here)?
> 
> We are looking to find a term to be used as value of the
> "variableRepresentation" property:
> 
>    ... a IriTemplate
>      template "...."
>      variableRepresentation ExplicitRepresentation
>      mapping [ ... ]
> 
> 
> > Anyway, assuming it's the 'output of the mechanism': a) and b) both
> > have 'Representation' again (do others find developers struggle with
> > the use of this term 'in general', or is it just me...?!).
> 
> I never talked to a developer that struggled with the term representation in
> general... but that doesn't mean much :-)
> 
> 
> > c) given that we're in the context of an IRI mapping template, why
> > isn't simply 'expandedValue' good enough? Outside of that context I
> > guess we'd just call it the 'iriTemplateExpandedValue' - which sits Ok
> > with me too I think...
> 
> We are not serializing those expanded values as structured data, we include
> them in an expanded IRI template
> 
>   /users/{id}
>   --> users/%22Markus%22%5E%5Ehttp://www.w3.org/2001/XMLSchema
> 

Ok, so I'm getting a little confused by all the above. If I understand correctly, it seems you weren't looking for a term to describe the output of the 'expansion mechanism' at all, but instead just looking for a term to identify the expansion mechanism in use, i.e. your trying to give a name to the process you detailed in [1].

So I assume that at the moment we have only two possibilities for this process (i.e. two possibilities for expansion):
1) The default case of using just using the lexical representation as-is, or...
2) The expansion process detailed by [1].

Hopefully I've understood this correctly so far, but then which one of the above was Ruben proposing we call 'ExplicitRepresentation'? I'm assuming its 2), but to be honest I'm not sure!

Instead I would have thought the following is much simpler (assuming I've understood the above correctly):

For 1) - 'noExpansion'
For 2) - 'datatypeAndLanguageExpansion'

(Yeah, I know, 'datatypeAndLanguageExpansion' is clunky, but really I'm just trying to make sure I'm understanding this discussion properly, and it is simple and explicit :) !)

> 
> >> 3) Do we really want to use two hats (^^) in the expanded representation
> >> knowing that we might introduce a Turtle representation in the future
> which
> >> will make it difficult to distinguish them by just looking at the
> resulting URL?
> >> Also unlike "$", the character "^" isn't allowed in a URL and needs to be
> >> escaped [3] to %5E.
> >>   a) use one hat (^)
> >>   b) use two hats as Turtle does (^^)
> >>   c) use another character such as $ which doesn't need to be escaped
> >> I strongly favor c)
> >>
> >
> > I still strongly favor b).
> >
> > Firstly, the 'expansionMethod' above should explicitly eliminate
> > any confusion.
> 
> But the expansionMethod can't be seen on the wire or in, e.g., access logs
> 
> > Secondly I think the less variation between the syntaxes of the
> > various potential 'expansionMethods' the better (i.e. the less
> > people have to learn and mentally differentiate). I don't agree that
> > sharing just this little bit of Turtle syntax could lead to
> > confusion (but of course that's easy for me to say given I'm very
> > familiar with Turtle!). But at least Turtle is a W3C standard, and
> > it happens to provide exactly the functionality we wish to apply
> > here. So simply referencing all the existing excellent Turtle
> > documentation here should make it a little bit easier to justify the
> > weird-looking '^^' to all the non-RDF people.
> 
> Well, we can't reference "all the existing excellent Turtle documentation"
> here as it isn't Turtle(-compatible). That's exactly what worries me. The
> goal was to create something simpler than Turtle. If we would make it full
> Turtle, we would also have to include angle brackets, support escape
> sequences, and things like """ and '''. I would like to reduce that
> variability to simplify implementations. A *simple* regex should be enough
> for parsing.
> 
> Turtle allows to serialize the string literal Markus in the following forms:
> 
>   "Markus"
>   'Markus'
>   """Markus"""
>   '''Markus'''
>   "Markus"^^<http://www.w3.org/2001/XMLSchema#string>
>   'Markus'^^<http://www.w3.org/2001/XMLSchema#string>
>   """Markus"""^^<http://www.w3.org/2001/XMLSchema#string>
>   '''Markus'''^^<http://www.w3.org/2001/XMLSchema#string>
> 
> ... and this doesn't even include the variability introduced by escaping
> [4].
> 
> I would like to have something without all that variability that should, if
> possible, also look nicer when embedded in a URL.
> 

Yep, I totally agree. I wasn't trying to imply we support 'full Turtle' here at all. I was just suggesting we borrow the Turtle syntax for datatype declaration (i.e. '^^'), that's all. I just meant when people question that 'weird looking' syntax, we can simply point them to "all the existing excellent Turtle documentation" for an explanation of that particular choice of syntax. In other words, I was suggesting we reference just a part of the Turtle specification, the part about specifying datatypes.

Coming up with a completely different, new syntax doesn't seem right to me, given Turtle does exactly this already. I don't think seeing '^^' would confuse anyone into assuming *full* Turtle support necessarily - we're just borrowing a little bit of a W3C standardized format that does exactly what we need here.

Likewise for using '@' for language tags, which seems agreeable to all...

> 
> 
> On 8 Aug 2014 at 14:31, Ruben Verborgh wrote:
> > What about the @ then for languages?
> 
> That's a good question. I would be open to change that as well but unlike
> the datatype component, the language-tag component is compliant Turtle
> (@en). Furthermore, @ can be used in most parts of a URL without escaping.
> 
> 
> 
> 
> >> [1] https://github.com/HydraCG/Specifications/issues/30
> >> [2] http://lists.w3.org/Archives/Public/public-hydra/2014Jul/0083.html
> >> [3] http://tools.ietf.org/html/rfc3986#section-2
> [4] http://www.w3.org/TR/turtle/#sec-escapes
> 
> 
> --
> Markus Lanthaler
> @markuslanthaler
> 
> 
> 

[1] http://lists.w3.org/Archives/Public/public-hydra/2014Jul/0083.html

Received on Tuesday, 12 August 2014 13:38:25 UTC