Section on "Breaking down data silos" on landing page

[axelreichwein]

One of the core ideas of OSLC is to break down data silos. Therefore, this key idea should be presented first on the OSLC landing page.

1st subsection

The Web has broken down barriers to connect documents (e.g. web pages, images) across different servers. Now, the Web is braking broken down barriers to connect data across different databases. This initiative is called Linked Data and was developed by the inventor of the Web Tim Berners Lee. Learn more on breaking down data silos through this HBR article.

• image overlaying a picture of corn silos and different labels such as PLM, ALM, ERP, IoT

2nd subsection

Linked Data can also be used to connect private data on the private enterprise Web, as done typically with OSLC REST APIs. Linked Data uses RDF as data format which can be described in many formats including JSON and XML. OSLC REST APIs expose data in RDF to enable the connection of data using open Web standards.

• image showing a cool graph

[berezovskyi]

Nice for inspiration: http://www.stardog.com/platform

[jamsden]

Actually data integration is the easy, and perhaps over-served part of integration. Behavior, UI and application integration is what we should be striving for. This is how OSLC is different. It provides resource preview and delegated dialogs for additional application UI integration. What we need to explore is extending OSLC with MQTT to add event/behavior integration.

On Nov 9, 2017, at 3:48 AM, Andrew Berezovskyi notifications@github.com wrote:

Nice for inspiration: http://www.stardog.com/platform http://www.stardog.com/platform — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/OSLC/oslc-site-hugo/issues/188#issuecomment-343086775, or mute the thread https://github.com/notifications/unsubscribe-auth/ABECqtTfECoQkgSkyt-CXgCjFaf6Hkewks5s0rx7gaJpZM4QXSgK.

[axelreichwein]

I think that data integration is not easy, considering all the incompatible databases, and proprietary integration platforms existing today preventing the easy connection of data across databases. I agree that OSLC covers very interesting aspects like resource preview and delegated dialogs. It would be great to explain it in more detail on the OSLC web site. I think that the landing page needs to highlight the most important fundamental challenges that are adressed by OSLC, and explain them using the simplest possible language without any technical terms.

[axelreichwein]

Having looked at other landing pages for data integration, or for APIs, I think that the landing page should provide much less text, and very briefly mention the main advantages of OSLC. So "breaking down data silos" would just be a headline next to an image on the landng page, and if the user clicks on it, then he gets directed to a page with more details.

[jamsden]

There are a lot of tools that support data integration. One of the reasons is so hard is because of the coupling these tools create between data consumers and providers. If we did integration at a higher level, integration of applications and semantics, this coupling would be reduced, the integration might be simpler, easier to maintain and deliver more value to users.

On Nov 11, 2017, at 7:31 PM, Axel Reichwein notifications@github.com wrote:

Having looked at other landing pages for data integration, or for APIs, I think that the landing page should provide much less text, and very briefly mention the main advantages of OSLC. So "breaking down data silos" would just be a headline next to an image on the landng page, and if the user clicks on it, then he gets directed to a page with more details.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/OSLC/oslc-site-hugo/issues/188#issuecomment-343704770, or mute the thread https://github.com/notifications/unsubscribe-auth/ABECqgvhYV3W2bvik_rg8YK2_qiEMxEhks5s1jxZgaJpZM4QXSgK.

[berezovskyi]

I think we are talking about the same thing here, @axelreichwein is trying to be more pragmatic and @jamsden sees the bigger picture. Take a look at @brianking slides at PDT https://www.slideshare.net/Koneksys/the-data-web-and-plm sl. 12.: proprietary data integrations are the new data silos.

So I agree that @axelreichwein points to a more immediate problem that needs to be resolved; I also agree with @jamsden that a lock-in–free data integration is not enough to sell OSLC to the prospective users. We need to aim at a deeper level of integration, namely the workflow integration.

Levels of interop have been widely made up of thin air: https://en.wikipedia.org/wiki/Conceptual_interoperability; those levels were systematically studied: https://www.kth.se/polopoly_fs/1.666670!/FULLTEXT01.pdf; but it is a very unclear field once we get past semantics (for one, because real world is an unclear field). I think what customers need beyond semantic interop is what the book about project management from Scott Berkun is about: "Making Things Happen".

I could say at this point that OSLC needs to catch up with OPC UA and stay ahead of WoT by incorporating the Action resource beyond the Automation spec, but this will be dishonest. If you will look at https://www.surveymonkey.com/results/SM-BQGN5TMT/ Q5, you will see that the two things that would really (ostensibly) drive adoption of OSLC is if competitors implement OSLC and if customers walk away from negotiations if OSLC support is missing. So we are more in the business of growing a two-sided platform rather than writing standards.

Back to the original question: I think that OSLC landing page still needs to sell mainly a linked data approach (5-star linked data, REST & RDF & LDP). Only when a visitor gets it, we can talk about what value does OSLC add to the vanilla REST implementation that serves RDF. If we talk about data silos as opposed to tool integration, it will be a tough sell for us. Just take a look at the landing page of one of the leading MDM solutions: https://www.informatica.com/products/master-data-management.html They sidestep the question of the lock-in, they say: your data is a mess, we can fix it in across a 100 industrial domains.

Maybe you should take a look at the https://oslc.github.io/why/ and refine what I wrote there. I think there is an issue for that, and Axel provided valuable suggestions there. The main question: who are we selling OSLC to? Second main question: what pains & gains do they have and how OSLC helps their jobs?

Finally, regarding the homepage. I totally agree that the following is irrelevant for a newcomer:

• Hypermedia API. First, the picture looks no different from a typical REST API and the main focus in the microservice community is API versioning and service discovery, which they have kinda solved w/o OSLC. Second, stakeholders will be asking immediately "why do I even need hypermedia?"
• OSLC Specifications. FIrst, it has technical inconsistencies: QM is part of ALM/PLM, not on the same level; same goes for "mobile" – a QM tool can be mobile-friendly, etc. We need to make sure the stakeholders understand that the set of domains is not set in stone, but instead that OSLC has a concept of domains and that they may integrate with tools that implement them as well as define their own.
• OSLC stack is too detailed. We can say that it is built on top of REST and (maybe) say that OSLC domains are defined via RDF vocabs (but then link to another page that answers the WTF RDF isn't that the thing that died more than a decade ago because JSON killed it?!).
• Ecosystem drawing fits better into About page. I couldn't care less about who is involved in OSLC and how it runs until I understand why do I need it.
• Solutions has the best picture of all, but we may want to draw and additional boundary around the silo 3 and show that it is hosted on-prem and its data does not go to the cloud.
• Implementations needs to open with neither IBM nor Lyo, but some other OSLC tools and adaptors, e.g. Jira, Magicdraw, Polarion, PTC Windchill. In that regard, could you please check if the list http://open-services.net/software/ is up-to-date?
• News should link to latest Brian's presentation at PDT Europe.

[jamsden]

Andrew, Thank you for the informative and enlightening response. I take two major points from your note:

"... two things that would really (ostensibly) drive adoption of OSLC is if competitors implement OSLC and if customers walk away from negotiations if OSLC support is missing."

And:

"… lock-in–free data integration is not enough to sell OSLC to the prospective users. We need to aim at a deeper level of integration, namely the workflow integration."

Its not really OSLC we’re trying to sell, rather its the value customers can get from integration they can’t get without it. OSLC is just a technological means to enable the integration.

Delivering that value will come from workflow, not data, API, or UI integration. Its the ability to script together things that do things in order to do other things that people need to do that delivers value.

This is what our industry is missing - the workflow integration piece that includes data, API, semantic, behavior, UI and application integration.

Finally, we need a way to do this that doesn’t need to rely on overly constraining standard, or result in coupling that makes the results unmanageable. These are the things that have inhibited other structure and API-based approaches to fail to meet their intended potential.

Perhaps the issues with RDF are a good example of what not to do. There was so much focus on inferencing and serialization formats, that the real value of RDF was lost in the fog. We need to balance the focus on what the technologies are with how they are used to deliver value.

On Nov 12, 2017, at 10:26 AM, Andrew Berezovskyi notifications@github.com wrote:

I think we are talking about the same thing here, @axelreichwein https://github.com/axelreichwein is trying to be more pragmatic and @jamsden https://github.com/jamsden sees the bigger picture. Take a look at @brianking https://github.com/brianking slides at PDT https://www.slideshare.net/Koneksys/the-data-web-and-plm https://www.slideshare.net/Koneksys/the-data-web-and-plm sl. 12.: proprietary data integrations are the new data silos.

So I agree that @axelreichwein https://github.com/axelreichwein points to a more immediate problem that needs to be resolved; I also agree with @jamsden https://github.com/jamsden that a lock-in–free data integration is not enough to sell OSLC to the prospective users. We need to aim at a deeper level of integration, namely the workflow integration.

Levels of interop have been widely made up of thin air: https://en.wikipedia.org/wiki/Conceptual_interoperability https://en.wikipedia.org/wiki/Conceptual_interoperability; those levels were systematically studied: https://www.kth.se/polopoly_fs/1.666670!/FULLTEXT01.pdf https://www.kth.se/polopoly_fs/1.666670!/FULLTEXT01.pdf; but it is a very unclear field once we get past semantics (for one, because real world is an unclear field). I think what customers need beyond semantic interop is what the book about project management from Scott Berkun is about: "Making Things Happen".

I could say at this point that OSLC needs to catch up with OPC UA and stay ahead of WoT by incorporating the Action resource beyond the Automation spec, but this will be dishonest. If you will look at https://www.surveymonkey.com/results/SM-BQGN5TMT/ https://www.surveymonkey.com/results/SM-BQGN5TMT/ Q5, you will see that the two things that would really (ostensibly) drive adoption of OSLC is if competitors implement OSLC and if customers walk away from negotiations if OSLC support is missing. So we are more in the business of growing a two-sided platform rather than writing standards.

Back to the original question: I think that OSLC landing page still needs to sell mainly a linked data approach (5-star linked data, REST & RDF & LDP). Only when a visitor gets it, we can talk about what value does OSLC add to the vanilla REST implementation that serves RDF. If we talk about data silos as opposed to tool integration, it will be a tough sell for us. Just take a look at the landing page of one of the leading MDM solutions: https://www.informatica.com/products/master-data-management.html https://www.informatica.com/products/master-data-management.html They sidestep the question of the lock-in, they say: your data is a mess, we can fix it in across a 100 industrial domains.

Maybe you should take a look at the https://oslc.github.io/why/ https://oslc.github.io/why/ and refine what I wrote there. I think there is an issue for that, and Axel provided valuable suggestions there. The main question: who are we selling OSLC to? Second main question: what pains & gains do they have and how OSLC helps their jobs?

Finally, regarding the homepage. I totally agree that the following is irrelevant for a newcomer:

Hypermedia API. First, the picture looks no different from a typical REST API and the main focus in the microservice community is API versioning and service discovery, which they have kinda solved w/o OSLC. Second, stakeholders will be asking immediately "why do I even need hypermedia?" OSLC Specifications. FIrst, it has technical inconsistencies: QM is part of ALM/PLM, not on the same level; same goes for "mobile" – a QM tool can be mobile-friendly, etc. We need to make sure the stakeholders understand that the set of domains is not set in stone, but instead that OSLC has a concept of domains and that they may integrate with tools that implement them as well as define their own. OSLC stack is too detailed. We can say that it is built on top of REST and (maybe) say that OSLC domains are defined via RDF vocabs (but then link to another page that answers the WTF RDF isn't that the thing that died more than a decade ago because JSON killed it?!). Ecosystem drawing fits better into About page. I couldn't care less about who is involved in OSLC and how it runs until I understand why do I need it. Solutions has the best picture of all, but we may want to draw and additional boundary around the silo 3 and show that it is hosted on-prem and its data does not go to the cloud. Implementations needs to open with neither IBM nor Lyo, but some other OSLC tools and adaptors, e.g. Jira, Magicdraw, Polarion, PTC Windchill. In that regard, could you please check if the list http://open-services.net/software/ http://open-services.net/software/ is up-to-date? News should link to latest Brian's presentation at PDT Europe. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/OSLC/oslc-site-hugo/issues/188#issuecomment-343744824, or mute the thread https://github.com/notifications/unsubscribe-auth/ABECqm0kaHTR1OzwkHcxQVJbrxfxUwWBks5s1w4PgaJpZM4QXSgK.

[axelreichwein]

@berezovskyi and @jamsden Thanks for sharing your point of view. This discussion is very useful.

@berezovskyi I agree 100% with "OSLC landing page still needs to sell mainly a linked data approach (5-star linked data, REST & RDF & LDP). Only when a visitor gets it, we can talk about what value does OSLC add to the vanilla REST implementation that serves RDF".

Talking of selling, we need take off our engineer hat and put on a sales hat. When selling, we can sell features (e.g. a button does this), advantages (e.g. this button makes the UI more user friendly) and benefits (e.g. team can collaborate better, less meetings, more productivity). The most convincing are benefits, in other words advantages that have demonstrated value. So the OSLC landing page needs to reflect benefits, not features, not advantages.

When applying this to Linked Data, I see the feature being the RDF standard, the advantage being that is a non-proprietary standard which can support integration and interoperability, and the benefit being that Linked Data will break down data silos in the same way as the Web has broken down silos between former incompatible hypertext systems.

@berezovskyi It is normal for a proprietary data integration platform to sidestep the topic of vendor lock-in because they create it :)

@jamsden I agree that the value of RDF has been lost in the fog of semantic reasoning, inferencing. We need to clarify that OSLC uses RDF just as a way to describe structured data identified by URLs, in the same way as HTML describes unstructured data identified by URLs.

@jamsden I agree that data integration is technically super simple and that OSLC has addressed more technically challenging concepts like delegated dialogs, configuration management and more.

@jamsden I agree that data integration is technically super simple (e.g. you just need HTTP, RDF and URLs), in combination ideally with a standard REST API like OSLC to do CRUD operations. Even though data integration is technically simple, doing it using open standards, which are web-compatible, has many benefits. I think that the OSLC landing page has to explain in detail these benefits (e.g. at a high level breaking down data silos, but then more specifically, traceability, consolidated reporting, workflow integration etc...).

The OSLC landing web page needs to show that vendors, end user organizations, universities, and consultants, support OSLC. This is important to show that there is already crticial mass behind the effort. As an example, I like how Microsoft Graph (https://developer.microsoft.com/en-us/graph/) shows briefly on the main landing page the main benefits, but also shows who is behind it, with what platform you can get started etc...So I think that IBM, and Lyo logos need to be super visible on the landing page next to other logos of other vendors, universities, consultants etc... I think that we could even add a section just showing logos of companies who support OSLC. After all, there is a lot of support for OSLC, it could be reflected right away on the landing page. Considering the special role that IBM has had related to OSLC, I also don't mind adding later a page explaining the history of OSLC and giving due credit to IBM for their fantastic work.

[gabrielfdac]

Hi all, allow me to jump in and share some ideas for the homepage. Taking into consideration your comments and some suggestions I created a new design for the homepage (link).

This should be an opportunity for us to put ourselves in the perspective of someone who has never seen anything about OSLC and try and think of the best way to inform this person.

Note that the content, which is undoubtedly paramount, is not there.

With simplicity in mind I trimmed down the sections with:

• A quick overview of the benefits of OSLC (With each being a link to either a specific page about that concept or to a global page which explain all of them)
• Getting Started: Here we can provide very quick and simple incentive words and them have it link to a page with more specific content.
• Supported By: This will achieve two things, a sense of credibility and importance for OSLC. Showcasing we can be taken seriously and that we've gotten support of many other organizations. (Those icons are but a fraction of all supporters, here we can highlight a few and then link it to a page which showcases the supporters in more detail.
• Where to go next: Here we can guide the visitor who scrolled all the way down to some other important pages. i.e Resources, contribute, why oslc, or which ever we deem relevant (Once again content not final, just took that from an older design).

These should hopefully do the job of directing those who land where to go next, without being confusing or over technical.

Please share your thoughts so I can improve the design and implement it to the website.

[berezovskyi]

@gabrielfdac this is so great! 😍

Let's try to rewrite the marketing text into 5 key points and a paragraph that will have a button lead to the Why OSLC page.

Will send you the link to the Drive folder via an email.

[hecsanchez]

Nice job @gabrielfdac! 👍

[berezovskyi]

I put some initial text for the value proposition, take a look.

[billchown]

@gabrielfdac that is a good way to go, and I will be looking to contribute some input from the way I think and talk about OSLC - lett's not forget the L in the name, it's not a D. @berezovskyi - where do I look for the text that you propose? Bill

[berezovskyi]

@billchown just forwarded you the link to the email I found in the OASIS roster.

[gabrielfdac]

Thanks! Glad it was well received, hopefully we can have awesome content and design right upfront!

[gabrielfdac]

Issue now being by tracked by #198