Re: Local identifiers in IriTemplates

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Am 14.12.2014 um 20:44 schrieb Markus Lanthaler:
> Hi Dietrich,
> 
> On 13 Dez 2014 at 11:06, Dietrich Schulten wrote:
>> Preparing the release of hydra-java with support for templates,
>> I wanted to ask for your opinions.
> 
> Awesome!
> 
> 
>> I understand templates as an equivalent to a GET http form,
>> especially since they have no facility to build a request body.
> 
> Yeah, they are similar to GET requests. If you define a property to
> be a hydra:TemplatedLink you can also associate operations (via 
> hydra:supportedOperation) to it and specify what data is expected
> in the body as usual. Currently there's no way to achieve that
> inline.. but it might actually be a good idea to also allow
> supportedOperation directly on a IriTemplate.
> 

Yes, that would also help to switch between representation as
schema.org Action and hydra:Operation. In schema:Action you can add
request descriptors to a templated resource. Right now I simply
couldn't render request descriptors if I render a hydra IriTemplate.

(What I have in mind is to render a schema.org Action on
potentialAction as an alternative to hydra:Operation and let the user
of hydra-java decide which way he prefers. If the affordance could be
rendered either way life is easier for me).



>> Let's say I want to search by some database identifier in
>> addition to the search by name, so I make hydra:search an array
> 
> I actually haven't thought about having multiple IRI templates
> with hydra:search.
> 

But it would be valid, would it? It occured to me only lately (when I
found myself struggling with the need for two custom properties
eventById and eventByName) that I could use hydra:search for both :)

>> A machine client could be programmed to start with some
>> knowledge about the context, for instance that it should use 4711
>> as a known hydra:localIdentifier when navigating the API.
> 
> And if you would use the URL instead of the ID in the mobile app
> you wouldn't have all of those issues altogether :-)

Yes, that is always the first choice. For instance, the API could
present an entry resource after login which already has the "correct"
customerId filled in on its related links and avoids templates altogether.

So for now, if someone absolutely needs to hand out templates with
variables that are not in a published vocabulary, he will have to
publish his own vocabulary and define those properties there. What
should that look like? I found one possible way to do so in the
Working Ontologist[1]. Applied to our Example:

Make ex:AcmeEvent a subClassOf schema:Event, then
ex:acmeEventId rdfs:domain ex:AcmeEvent
ex:acmeEventId rdfs:range xsd:Integer
ex:acmeEventId a owl:FunctionalProperty
ex:acmeEventId a owl:InverseFunctionalProperty

Now I could use:

"hydra:template": "http://example.com/events/{eventId}",
"hydra:mapping": [
{
"hydra:variable": "eventId",
"hydra:property": "ex:acmeEventId"
}
]

At least we assert in a machine-processible way that the value of
acmeEventId is in fact an identifier for an AcmeEvent. Each event can
have at most one acmeEventId (functional) and two AcmeEvents sharing
the same acmeEventId must be the same (inverseFunctional).

Why would I want to do that? I could tell a client "if you are asked
for a both functional and inverseFunctional property of a subclass of
schema:Event, then use 4711" - rather than having to tell it about a
vendor-specific property acmeEventId. Bingo - no vendor-specific
knowledge needed in advance.

Would that be correct? If so, then this probably could also be
generated somehow, at least with Spring-Hateoas which has a way to
mark attributes as Identifiable.

Best regards,
Dietrich


[1] Allemang, Hendler: Semantic Web for the Working Ontologist, p.198
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (MingW32)

iEYEARECAAYFAlSOqn0ACgkQuKLNitGfiZPhWACbBzceJeJLB2rMVGPNtrfiaqZp
oBAAnjpwq94GoWVXhHUvUGxGMvv4XALH
=wrBv
-----END PGP SIGNATURE-----

Received on Monday, 15 December 2014 09:32:17 UTC