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


>>>> 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 14:52:35 UTC