Re: Search Algorithms for Hydra

Hi Karol,

Thanks for this explanation.

What I am missing in the Hydra specification right now is basic meta
data like I've pointed out already:

* The name of the service
* a short description in natural language
* License being used
* Categories on which the Web Service operate (for example "Car-Manufacturing")
* Preconditions and Effects (Does the Service depend on another Service?)

For example the entrypoint of the event API demo:
(http://www.markus-lanthaler.com/hydra/event-api/)

```
{
    "@context": "/hydra/event-api/contexts/EntryPoint.jsonld",
    "@id": "/hydra/event-api/",
    "@type": "EntryPoint",
    "events": "/hydra/event-api/events/"
}
```

This is the first response a possible client will get. Is this correct?
Or will the client directly ask the vocab for the semnatic API
description? If so: How does the Client know that the client speaks with
the right service? This is basically my research question, because I
want to make Hydra Services semantically discoverable.

As far as I understood you, you said that the client don't need to
'find' any service, because it's hardcoded and Hydra just provides a
same vocabulary for decoupling.

My question is: Wouldn't it be possible to 'add' a few meta tags to the
entrypoint like this:

```
{
    "@context": "/hydra/event-api/contexts/EntryPoint.jsonld",
    "@id": "/hydra/event-api/",
    "@type": "EntryPoint",
    "events": "/hydra/event-api/events/",
    "name": "Event-API",
    "description": "A simple example for a Hydra based event API",
    "license": "GPLv3"
    "categories": ["events", "Halloween"]
    ".... maybe a few more.. even with proper context"
}
```

I don't expect an implementation from you guys, I just want to know if I
am on the right way and if hydra could suit my requirements.

christian




On Thu, Feb 20, 2020 at 10:44:25PM +0100, Karol Szczepański wrote:
> Hi Christian
>
> In short, hydra is supposed to let both client and server talk using
> same protocol expanded with some common vocabulary so the server can
> drive the client resulting in client being smart and decoupled.
> How the server can drive a client depends on that client - it will be
> something different for an automated one (i.e. some details allowing
> automatic decision making) and something different for human operated
> app (i.e. what can be done and how it should be displayed).
>
> Having this in mind, while search algorithm may not fall into that
> circle of interest, "meta service description" may fit.
> Hydra is a meta service description to some degree - hypermedia
> controls introduced by hydra vocabulary are additional pieces of
> information interleaved with raw data that can be used by the clients
> to interact with the data and the server.
>
> Feel free to deliberate more on your ideas - maybe there is something
> we could make hydra better.
> In worst case scenario hydra may introduce some "plugs" that could get
> that vocabulary opened for some extensions bringing features you
> desire.
>
> Best regards
>
> Karol
>
> czw., 20 lut 2020 o 20:58 Christian Rebischke
> <christian.rebischke@tu-clausthal.de> napisał(a):
> >
> > Hello Tomasz,
> >
> > thank you for your mail. Let me explain you my current work:
> >
> > I am working in a small research group that want to enable developers to
> > upload semantic described Web services for emergent genesis.
> >
> > The goal is that a user can describe their requirements and the
> > plattform will semantically search for different services that meet this
> > requirements and compose them to an emergent service.
> >
> > We thought that Hydra is might a good choice for solving this problem.
> > At least the part about semantic input/output and API description.
> >
> > I am the person who is responsible for service discovery, hence I had a
> > look on different semantic Web service descriptions like OWL-S, WSMO,
> > Hydra, WebAPI on schema.org and many others.
> >
> > OWL-S seem to have anything what we would need, but it's old and
> > therefore there are no existing libraries for it anymore. That's why I
> > thought Hydra is might a good choice for the project.
> >
> > Yesterday I had a proper look on the API description and the Web Service
> > Vocabulary. The input and output API description looks fine for me, the
> > only thing what is missing is meta data for the service like "Name",
> > "Description", "License", maybe some sort of "Preconditions" or
> > "Effects".
> >
> > What are "preconditions" and "effects"? This is a concept from OWL-S.
> > It describes adjustments or changes in the physical world. For example,
> > when you trigger a smarthome web service and the smarthome web service
> > is going to adjust the temperature in a room, this might be an effect.
> > Another service can have as precondition, that the room temperature is
> > not too low, this would mean that I would need a sensor service in my
> > "Service composition" for measuring the room temperature first.
> >
> >
> > So much about my project. My next question is:
> >
> > Is this actual from interest for this group? So, are you guys interested
> > in some sort of search algorithm or meta service description for hydra
> > or is this out of scope of Hydra?
> >
> > Best regards,
> >
> > Christian
> >
> >
> > On Wed, Feb 19, 2020 at 07:28:49PM +0100, Tomasz Pluskiewicz wrote:
> > > Hello Christian
> > >
> > > That is a very interesting question and indeed a subject which comes back occasionally in the context of Hydra and other API specifications.
> > >
> > > At the moment there does not appear to be a ready one-size-fits-all solution which would discover Hydra that way. I cannot really comment on the linked package though.
> > > Hydra itself is probably not expressive enough to facilitate that.
> > >
> > > However, because about Hydra is built on top of RDF and Linked Data technologies, it would be fairly easy to start implementing a custom extension to allow such discovery.
> > >
> > > Please let us know a little more about your work:
> > >
> > > 1. What kinds of requirements would the API expose, in human terms perhaps
> > > 2. Would those be public APIs or a closed environment (such as multiple APIs within an organization)
> > >
> > > Best,
> > > Tom
> > >
> > > On 19 February 2020 at 14:32:56, Christian Rebischke (christian.rebischke@tu-clausthal.de) wrote:
> > > > Hi,
> > > >
> > > > is there any library/client for searching for hydra web services and
> > > > matching them against a fixed set of requirements?
> > > >
> > > > Imagine the following:
> > > >
> > > > I have a fixed set of requirements for a Web Service (either described
> > > > semantically or natural language or whatever) and i want to find a
> > > > matching service for this requirement.
> > > >
> > > > Is there something for hydra?
> > > >
> > > > What I've found so far is an `api-doc-parser`[1]. But i am not sure if
> > > > this is enough for finding a matching hydra service.
> > > >
> > > > Grüße
> > > > Christian
> > > >
> > > > [1] https://github.com/dunglas/api-doc-parser
> > > >
> > > >
> > >
> >

Received on Friday, 21 February 2020 11:36:01 UTC