I am implementing an OSLC Automation provider and there is something I am not sure about when it comes to Automation Plans.
Imagine an Automation provider for a bunch of testing tools. It should allow clients to submit a program to be analyzed by one of the analysers, and then allow them to get the result.
Looking at the example provided in the OSLC Automation Primer (even though the example is a build tool), I am unsure what the program to analyze would map to. The example looks like there is an Automation Plan specific to one program to be built. Now the OSLC Automation specification only requires a GET capability for Automation Plans so it seems like Automation Plans are meant to be read-only for clients. How would the Automation Provider build other programs if the POST capability for Automation Plans isnt required?
I see two options for my analysis example:
The provider has an Automation Plan for each analysis tool, and the Automation Plans only have a GET capability. The program to analyze is one of the input parameters specified in an Automation Request.
The program to analyze is a part of the Automation Plan. The user creates an Automation Plan specifically for each program.
Is this an implementation choice or is one of the options preferred by the specification?
I’d be very grateful for some thoughts or suggestions!
I think the idea behind not requiring POST on Automation Plans is that they can be created/defined in any way possible (eg I can imagine you parsing a .gitlab-ci.yml file from a repo and creating an Automation Plan per build stage). It does not mean the Automation Plans are supposed to be static.
I think both of your options are valid. If you think that analysis will be provided as a service, option 1 sounds good to me. If you extract (and live-update) the Automation Plan for analysis from Gitlab CI file (e.g. by defining a custom analysisstage), I would go for option 2.
I have also asked a colleague with OSLC Automation hands-on experience (I have none, to be clear) to look at your question and provide his opinion too.
Thanks! Seeing the automation provider as a testing service or as a part of a Gitlab CI stage is interesting. I have already implemented the first option for another testing service application, and my current project seems to be more similar to the Gitlab CI scenario.
I’ll be on the lookout for your colleagues answer in case he has any more thoughts about this.
“Semantics automation”? You can’t automate semantics.
“Vocabulary from existing OLAP DB, Datawarehouse”. OSLC resources follow the vocabulary, existing DBs usually have a schema.
“OSLC Resource shape used for knowledge graph”. Shapes are used on vocabulary resources. All of them may be used for building a knowledge graph, but those are not related.
Please formulate the question better and we will try to help.
This group name “OSLC Automation- Automation Plan semantics”. my undestanding is, automation plan smantics is analogous to develop semantic schema.
However, I used “Semantic Automation” term for automation and preparation of data dictionary. Developing data dictionry will help me to define class, objects. which is nothing by RDF ontology objects.
Is my understanding right that data dictonary is nothing but OSLC vocabulary of various domains.
To generate OSLC resource shape, i can create axioms and reasons, which will further help in defining OSLC resource shape, which is nothing but my triple store.
Let me know if my view from analytics perspective is aligned with tenets of OSLC for LDP.