RE: Local identifiers in IriTemplates

On 15 Dez 2014 at 10:31, Dietrich Schulten wrote:
>>> 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.

Yeah, it's probably a good idea to allow it and quite straightforward to do.
Can you (or anyone else) think of any problems arising from allowing it? I
can't at the moment so it should be fine.


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

Sure.. we didn't forbid it :-) On a more serious note: at some point we
should document the cardinality expectations to ensure that different
clients interoperate.


> 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 :)

Right.. even though you would more or less achieve the same with having just
a single template with two optional parameters. The only thing you can't
express in that case is that (at least) one of the parameters is required.


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

Something like

   ex:acmeEventId rdfs:label "The internal, unique ID of an event"

should be more than enough to get started. The client needs to be programmed
to understand this concept anyway.. unless it falls back to let the user
input the data in which case a clear label should suffice. Obviously, if you
also define a range, you can create more sophisticated UIs (input
validation).


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

Exactly.


> 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).

Right. To get started, I would keep things simple and pragmatic. Information
that the client can't (or at least won't) use in an automatic manner can be
left out. You can always describe these things in more details later.


> 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.

Hmm... not sure whether that's such a good idea. What if you have multiple
of those identifiers? Think of, e.g., SKU and EAN or ISBN numbers. 


> 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.

I haven't thought too much about it but my gut feeling is that you will run
into all kinds of issues with such a heuristic. Why do you try so hard to
work around the fact that the number "4711" is a vendor-specific,
proprietary identifier? If it is, why can't it be expressed using a
vendor-specific, proprietary property?


Cheers,
Markus


> [1] Allemang, Hendler: Semantic Web for the Working Ontologist, p.198


--
Markus Lanthaler
@markuslanthaler

Received on Tuesday, 16 December 2014 22:08:52 UTC