Re: Search Algorithms for Hydra

Hello Christian

Extending what I wrote in my earlier email, while Hydra Core may not necessarily readily specify directly how you would define that information.

However, there are definitely building blocks which allow it. Let me elaborate inline.

Tom

On 21 February 2020 at 12:36:55, Christian Rebischke (christian.rebischke@tu-clausthal.de) wrote:
> 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

These two should be simple. Hydra uses its hydra:label and hydra:description in other contexts. 
Also, IIRC, analogous rdfs/schema terms are also explicitly allowed.
It would seem only logical to explicitly mention in the spec that the service as a whole can be annotates the same way.

> * License being used

This probably falls out of scope of the spec itself, which aims to mainly provide hypermedia control descriptions.
Nothing stops you from inspecting an API for cc:license [1] or schema:license [2]. 
Again, we might add a paragraph to suggest that, yet without a string mandate IMO. 

[1]: https://prefix.zazuko.com/cc:license
[2]: https://prefix.zazuko.com/schema:license 

> * Categories on which the Web Service operate (for example "Car-Manufacturing”)

I find this one a little vague but if the purpose is essentially “tagging”, then again sounds like schema.org might define some useful terms, such as schema:category [3]

[3]: https://prefix.zazuko.com/schema:category

> * Preconditions and Effects (Does the Service depend on another Service?)

This is turn is quite specific and at the same time more interesting.

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

Not necessarily "the first”. A client can begin from any resource URL (think browser bookmarks). The response should include a HTTP Link header with the hydra:apiDocumentation relation. This is where most of the service’s capabilities will be described.

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

Definitely. As have shown, by using Linked Data technologies at its core, you are free to
extend your APIs with any non-standard metadata, which we may later standardise or recommend
if they prove useful and generic enough.

I think it would be very useful if your research results in an analysis of possible RDF terminology (vocabularies/ontologies) which enable the goals you describe and we could take it from there.

That said, standardisation is hardly necessary on a global level if one intends to operate in a closed environment,
such as within an organization.

>  
> 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
> > 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 15:43:02 UTC