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

Gregg Kellogg
gregg@greggkellogg.net

On Aug 12, 2014, at 7:51 AM, Markus Lanthaler <markus.lanthaler@gmx.net> wrote:

> 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!?

I think it would be wise to stick to the mechanism defined in RFC6570 "URI Template". Going beyond this requires a really compelling use-case IMHO.

Gregg

>>>>> 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 ;
>     ...
>   ]
> 
> 
>>> 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.
> 
> 
>> 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
> 
> ... 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)?
> 
> 
>> 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.html
>>>>> [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 Tuesday, 12 August 2014 16:55:52 UTC