- From: Christian Rebischke <christian.rebischke@tu-clausthal.de>
- Date: Fri, 21 Feb 2020 12:35:42 +0100
- To: Karol Szczepański <karol.szczepanski@gmail.com>
- CC: Tomasz Pluskiewicz <tomasz@t-code.pl>, Hydra <public-hydra@w3.org>
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