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

Whoops - I sent this reply just to Markus instead of the whole mailing list...

-----Original Message-----
From: McBennett, Pat 
Sent: Thursday, August 14, 2014 1:53 PM
To: 'Markus Lanthaler'
Subject: RE: Moving forward with ISSUE-30 (IRI template expansion)

> -----Original Message-----
> From: Markus Lanthaler [mailto:markus.lanthaler@gmx.net]
> Sent: Tuesday, August 12, 2014 3:52 PM
> To: public-hydra@w3.org
> Subject: RE: Moving forward with ISSUE-30 (IRI template expansion)
> 
> On 12 Aug 2014 at 15:37, McBennett, Pat wrote:
> > Markus Lanthaler wrote on 11 Aug 2014 at 15:57:
> >> 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.
> 
> Right
> 
> 
> > 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?
> 
> Yes, that's at least what I want :-)
> 
> If you want the template itself to be processed differently, then you 
> are changing the semantics of RFC6570. In other words, the IRI 
> template isn't
> RFC6570 conformant anymore. This touches ISSUE-17 [6] for which we 
> have a
> 
>     PROPOSAL: Introduce a datatype for RFC6570 IRI templates, but
>     don't change the range of  hydra:template . Update the Hydra
>     JSON-LD context to type-coerce template automatically.
> 
> Perhaps we should try to close ISSUE-30 and ISSUE-17 at the same time 
> instead of postponing the decision on ISSUE-17!?
> 

Aha! Ok, so now I get it. And, yes, I agree that introducing a 'hydra:rfc6570Template' datatype could resolve issue 17, and help with issue 30, while also aided general comprehension (e.g. I was aware of URI Templates of course, but I hadn't read RFC6570, and I wasn't aware of how sophisticated they really are).

> 
> >>>> 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].
> 
> I'm not sure where you draw the line.. especially that the whole 
> process of turning a IRI template + variables into a IRI is called expansion as well.
> 
> 
> > 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].
> 
> Right. I wanted to limit it forever to these two alternatives. It 
> seems, however, that the majority of the group wants to keep this 
> extensible. Thus, we need to define a "variableRespresentation" 
> property and, for the time being, two IRIs identifying (1) and (2).
> 
> 
> > 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!
> 
> He proposed to call (2) "ExplicitRepresentation" as that 
> representations explicitly differentiates between IRIs and literals 
> (and literals with different datatypes and/or language tags). 
> According to (1), the IRI http://example.com and the literal 
> "http://example.com"^^xsd:string are indistinguishable (but in most 
> cases it doesn't matter as the server will know what was meant).
> 
> 
> > 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 :) !)
> 
> I'm not sure what you are trying to propose here (the terms you 
> propose are lowercased suggesting they are properties), so, could you 
> please complete the following example:
> 
>    [
>      a IriTemplate ;
>      template "http://example.com/users/{id}" ;
>      mapping [
>        a IriTemplateMapping ;
>        variable "id" ;
>        property ex:userId .
>      ]
>    ]
> 
> The thing we are discussing here would look as follows:
> 
>    [
>      a IriTemplate ;
>      template "http://example.com/users/{id}" ;
>      variableRepresentation hydra:ExplicitRepresentation ;
>      ...
>    ]
> 

Yeah, sorry about the capitalization - my bad. But now that I'm back on track, I think I prefer 'variableExpansion' now instead of 'expansionMethod', so we get:

   [
     a IriTemplate ;
     template "http://example.com/users/{id}" ;
     variableExpansion hydra:NoExpansion ;
     mapping [
       a IriTemplateMapping ;
       variable "id" ;
       property ex:userId .
     ]
   ]

...or...

   [
     a IriTemplate ;
     template "http://example.com/users/{id}" ;
     variableExpansion hydra:SimplifiedTurtleExpansion ;
     mapping [
       a IriTemplateMapping ;
       variable "id" ;
       property ex:userId .
     ]
   ]

Or alternatively, 'hydra:ExpansionNone' and 'hydra:ExpansionSimplifiedTurtle' (as I generally recommend left-justifying names because it groups related things together alphabetically. But some people don't like it at all, so it's just a suggestion).

> 
> >> 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.
> 
> But in Turtle the IRI following the two hats in enclosed in angle 
> brackets
> (".."^^<http://...>) so we can't even reference that part. And that's 
> part of my reluctance to use the two hats. A lot of people familiar 
> with Turtle won't read the spec carefully enough to notice that we omit the angle brackets.
> 

D'oh! Great point.

> 
> > 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.
> 
> In my opinion it's too little to justify an extremely ugly and hard to 
> debug result
> 
> 
> http://example.com/question-
> for/%2242%22%5E%5Ehttp://www.w3.org/2001/XMLSche
> ma#integer
> 
> vs e.g.
> 
> 
> http://example.com/question-
> for/'42'$http://www.w3.org/2001/XMLSchema#intege
> r
> 

Yep, that's a great example illustrating the 'cost' of being more Turtle-compliant.

> ... but apparently I'm the only one with that concern. So, what about 
> the alternative to align this closer to Turtle, i.e., also requiring 
> the angle brackets where Turtle requires them and calling the 
> representation SimplifiedTurtle (simplified because we don't support prefixes and escaping)?
> 

+1 - I still think this proposal is worth the cost you illustrate above over creating something completely new.

> 
> > Likewise for using '@' for language tags, which seems agreeable to 
> > all...
> 
> As I already said
> 
> >> 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.htm
> >>>> l [3] http://tools.ietf.org/html/rfc3986#section-2
> >> [4] http://www.w3.org/TR/turtle/#sec-escapes
> > [1] 
> > http://lists.w3.org/Archives/Public/public-hydra/2014Jul/0083.html
> [6] https://github.com/HydraCG/Specifications/issues/17
> 
> 
> --
> Markus Lanthaler
> @markuslanthaler
> 
> 
>

Received on Friday, 15 August 2014 11:16:50 UTC