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

> -----Original Message-----
> From: Markus Lanthaler [mailto:markus.lanthaler@gmx.net]
> Sent: Saturday, July 26, 2014 3:46 AM
> To: public-hydra@w3.org
> Subject: Moving forward with ISSUE-30 (IRI template expansion)
> 
> Apparently there's no consensus yet on ISSUE-30 [1]. I'm trying to summarize
> the of open questions in this mail. I'll also add my personal opinion about
> these questions. Please add your opinion by replying to this mail and leaving
> the question as well as the other people's responses-
> 
> Shall we use a flag (hydra:expandedRepresentation) to switch to "expanded
> representation" or should this be an extensible attribute
> (hydra:valueRepresentation)?
> -------------------------
> Markus: I don't see much value in making this extensible. I find it more
> important to increase interoperability by just having two ways to expand IRI
> template values.
> 

Just to make sure I understand this issue correctly, Markus prefers a simple flag 'hydra:expandedRepresentation', which if missing (or present with a value 'false') means take the value literally, but if present and 'true' means apply the proprietary (i.e. *not* Turtle) expansion mechanism Markus detailed.
 
Ruben suggests a value attribute instead ('hydra:expansionMechanism' seems like a better name than 'hydra:valueRepresentation' to me?). This allows us to add new, different expansion mechanisms in future, i.e.:
	1. Does _x have a 'hydra:expansionMechanism'? If not, take the value literally. If yes then...
	2. Switch on the value of '?expansionMechanism' from 'SELECT * WHERE { _x    <hydra:valueRepresentation>    ?expansionMechanism }'
And we'd have to define a value for the default expansion algorithm detailed by Markus, e.g. 'hydra:simpleExpansionMechanism' or 'hydra:simpleAndDefinitelyNotTurtleExpansionMechanism'. It would then be very easy to allow full-blown Turtle expansion by simply adding a new 'hydra:turtleExpansionMechanism'.

So it seems to be the difference between:

(flag)	'SELECT * WHERE { _x    <hydra:expandRepresentation>    ?expansion }'
	if ((expansion == null) || (valueOf(expansion) == 'false')) {
		[Use value as literal];
	} else {
		[Expand value as detailed by Markus];
	}

(value)	'SELECT * WHERE { _x    <hydra:expansionMechanism>    ?expansionMechanism }'
	if ((expansionMechanism == null) || (valueOf(expansionMechanism) == 'hydra:expandAsLiteral')) {
		[Use value as literal];
	} else {
		switch (valueOf(expansionMechanism)):
			case ('hydra:simpleExpansionMechanism'):
				[Expand value as detailed by Markus];
				break;

			default:
				throw new RuntimeException("Unknown expansion mechanism!");
	}

Currently I agree with Ruben. It is a little extra work, but really not much. And I'd just worry that introducing a simple flag now will just create noise and confusion later when the inevitable 'I need slightly different behavior than the current *one-and-only* expansion algorithm' request comes along (such as requests for escaping, see final point below).

So +1 for the extensible value attribute.

> 
> Shall we use two ^ when adding the type or like Turtle two ^
> -------------------------
> Markus: IMO one ^ is enough. Actually, I would prefer another character
> such as $ as it makes it clearer that the serialization is *not* Turtle.
> 

+1 for two ^. Turtle is a W3C standard, and I think its adoption can only grow ('cos it's so intuitive), so borrowing as much of its syntax as possible is a good thing. (And I'm also thinking of the slight differences originally between the Turtle syntax for 'PREFIX' and the SPARQL syntax for 'PREFIX' - that was crazy, so they changed Turtle to align them. I think we should align where possible too.)
+1 for making it clear that we do not support the full-blown Turtle syntax.

> 
> Must the datatype xsd:string always be omitted?
> -------------------------
> Markus: I'd would be fine making this a "the datatype xsd:string MAY be
> omitted"
> 

+1

> 
> Must the datatype rdf:langString always be omitted/present?
> -------------------------
> Markus: I'd say "the datatype rdf:langString MAY be omitted if a language
> tag is present"
> 

+1

> 
> 
> There seems to be consensus that by default, IRI template values should be
> expanded by only using the lexical representation of the value or the IRI (no
> quoting). Does anyone disagree with this? There also seem to be consensus
> that we don't want to do any escaping of strings/IRIs, right?
> 

+1 (since if we have an extensible expansion mechanism, we can easily add these capabilities later by introducing new 'quoting' or 'escaping'-capable expansion mechanisms, right?)

> 
> [1] https://github.com/HydraCG/Specifications/issues/30
> 
> 
> --
> Markus Lanthaler
> @markuslanthaler
>

Received on Saturday, 26 July 2014 08:29:46 UTC