W3C home > Mailing lists > Public > public-hydra@w3.org > July 2014

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

From: Ruben Verborgh <ruben.verborgh@ugent.be>
Date: Mon, 21 Jul 2014 21:31:14 +0200
Cc: public-hydra@w3.org
Message-Id: <7CEFB969-DB5E-489D-A7EF-D7CC33840B4E@ugent.be>
To: Markus Lanthaler <markus.lanthaler@gmx.net>
>>>    _: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.



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

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:29:42 UTC