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.

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.


> 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


>> 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.



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

Received on Monday, 11 August 2014 14:57:09 UTC