Re: Call for consensus on defining IRI template expansion (ISSUE-30)

>>>    _:x hydra:valueRepresentation hydra:ExpandedRepresentation.
>>> with
>>> 
>>>    _:x hydra:valueRepresentation hydra:ValueRepresentation.
>>> being the default.
> 
> I could live with that if we can justify that increased complexity.

Note that it's not necessarily more complex;
with a boolean flag, you have to check whether the argument is true or false.
Here, you have to check whether it's ExpandedRepresentation or ValueRepresentation.
Simple string matching in both cases.

> IMO there are two classes of applications that we have to consider here: RDF-based applications (triple store on the server side etc.) and non-RDF-based (mostly applications that work in the realm of JSON-LD instead of RDF). Is there anything in between which we need to handle?

I think that, as a prerequisite, Hydra should work with existing (REST) HTTP interfaces.
That is, if a server has decided to encode values in a certain way,
the description should reflect this; i.e., the application should not be updated to allow description.

So anything in between: well, there's many kinds of RDF-based and non-RDF based;
it's not just two categories that exactly map to two was of parameter handling.

>>>>  - the datatype xsd:string is always omitted
>>> 
>>> SHOULD be omitted, I'd say
> 
> Why not MUST? Just for the record, I could also live with MUST NOT. What's a good reason to (not) include it despite a SHOULD (NOT) in the spec?

It's just a datatype like any other. I would not disallow it for that reason.

>>> I strongly suggested, as Gregg has said, to stick to two of then: ^^.
>>> Just because of convention in Turtle (They're the ones
>>> that should have decided to only use one.)
> 
> Yep, that ship unfortunately has already sailed a long time ago. I don't have a strong opinion about this but we have to make it very clear that this serialization is *not* Turtle.

+1

Best,

Ruben

Received on Monday, 21 July 2014 19:31:48 UTC