Hello everyone, I am Shouxuan Wu, a Ph.D. candidate whose research interest is data integration and inter-operation in MBSE. I have learned a lot in OSLC forum. So I want to consult following questions with the community and get a broader opinions from all of you:
1. What’s the main differences between the integration approach based on OSLC and ontology approach(OWL or RDFs)?
2. Why the Service concept in OSLC core specification only provide query capability and creation factory? Does it means that the common Update and Delete of C.R.U.D in software domain need to be addressed by OSLC domain specification like OSLC change management?
3. What are the main problems facing OSLC evolution today ? As an advanced technology, what problems can’t OSLC solve ?
Here’s my take on questions 2 and 3. I’ll leave question 1 to people more knowledgeable on these differences.
The service concept does not need to care about the update and delete because, following the HTTP and REST recommendations, those are handled directly on the resource. So you need a Service to create a resource but, once you have the resource, you can update it using a PUT/PATCH and delete it using a DELETE call.
(A) I believe that OSLC as it is today faces mainly 2 issues:
communicability/marketingability: it appears as something that is rather complex/technical when if integrations were following the best practices/recommendations, there would be a very much easier process for end users understanding the benefits. This is mostly because the specifications are mostly made of MAYs and SHOULDs, rather than MUST. An OSLC compatible application can limit itself to some API capabilities when the end-user would expect it to support the ability to do linking with delegated UIs and show previews. We are actively working on this problem by defining OSLC Profiles. Work on these profiles will begin as soon as today in the OSLC OP meeting. Anyone can join these and contribute, so feel free to.
discovery: some discovery mechanisms exists but they’re not fully part of the specification. Typically, the rootservices document remains an IBM specification and was not open sourced. Still, this rootservices document remains the most common way for most implementations to share their capabilities (from friending to authentication, to TRS, etc.).
(B) As for the second question “what problems can’t OSLC solve”, I think OSLC is complex, but provide a wonderful set of recommendations for integrating products. You can do linking, previews, add decorators to your links, do live reports on your data + that of other tools. There are certainly some limitations, but only one recently discussed I can think of: OSLC Query does not provide support for answering “give me all resources that don’t have the following property”. Additional features and specifications would be nice, with some actively discussed, like TRS Push, the Link Index, as well as Delivery and history mechanisms in the TRS specification.
Overall, there remains room for improvement but the tech is already really solid IMO.
I am not sure it works to compare the two, but I can relate them to each other. OSLC uses RDF to solve the integration problem.
OSLC does not use OWL to represent full-blown ontologies… Instead the simpler RDFS “ontology” was deemed sufficient for the integration needs at hand. But this does not hinder solutions from further using OWL.
Note also that OSLC specifies how to use RDF, which is otherwise missing from the RDF stack. For example, the use of Query, Creation Factories, REST C.R.U.D., etc.
I agree with @Frej’s responses otherwise.
It is always tricky to answer the question of “what problems can’t OSLC solve”. IMO people get the impression OSLC should solve all integration problems. Then the list of missing features is endless. We can focus instead on what OSLC solves (a basis for creating traceability), and the rest we can build upon.
Another question would however be “would taking an OSLC approach be a hinder to solve some other problems?”
Thanks for your answer. Notice that you emphasize OSLC use RDF to solve integration problems.
But what indeed motivate us to use OSLC instead of common RDF/OWL directly to solve integration problems? Based on my experiences for developing OSLC adaptors, OSLC can be considered as a way for simplifying the configuration of RDF now. If this idea is correct?
I am not sure how you can use RDF/OWL to solve an integration problem. RDF/OWL is just the language or mechanism to represent information.
Can you exemplify? How can you use RDF (without something like OSLC) to - say - create a resource?
Sorry for not figuring out the difference between solving integration problems and information representation. I think I see what you mean. For example, the integration problems now is adding a Row of Excel file in Word file. Someone uses XML schema in OWL to describe the information pattern of these rows, such as the id and style of rows, then he passes through these OWL files to others. For you, if it means that these OWL files is only information representation or storage for rows and it still lacks the mechanism/formalism for representing the action for adding these rows ?
(sorry I dont know if I express it clearly, If clearly, is it possible to add the XML schema of creator, create action in OWL files?)
OWL is insufficient to describe what RDF properties resources of some type must have, or might have. OSLC uses resource shapes to satisfy that requirement. OSLC specifications use resource shapes to describe resources. Remember that the shape of a resource of some type might be different between different service providers. Often service providers are associated project areas, and custom properties might vary across project areas.
What is important is that resources in some application domain have well-defined common RDF properties, and that clients can discover those properties through resource shapes.
Could you explain the OWL is insufficient to describe what RDF properties resources of some type must have, or might have by some examples? Giving a typical scenario is better.
OWL allows you define classes and properties. But you cannot define which properties must or may be used for a class. That’s what OSLC resource shapes do. You might also want to look at SHACL that addresses similar requirements.
delegated dialogs for creation and selection - commonly used in integration scenarios where a user wants to create a link to some resource in another application domain or server.
resource preview - supports rich hover
creation factories - allows a client to create resources of some type
query capabilities - allows a client to discover resources of some type that are of interest in some integration scenario
Having a common vocabulary is a start, but is, by itself, insufficient to support the richness of integration scenarios that users want.
OWL allows you define classes and properties. But you cannot define which properties must or may be used for a class.
OWL allows you to define classes and properties. For example, class “Person” and “Car” are connected by object property “have”. This demonstrates that the property “have” may be used in Class “Person”. Why did you say “cannot define which properties must or may be used for a class”?
Your example is relating two rdfs:Class instances. What’s needed is to relate an rdfs:Class with one or many rdf:property definitions. If you have a look at the ontologies published for OSLC, you will see there is nothing that connects a class to the properties that class might have. That is fulfilled with OSLC resource shapes. Another place where you can see this requirement is in SHACL shapes (which OSLC has not adopted).
Although it relates to SHACL (and not OSLC) Shapes, I recall this short tutorial helped be experiement and understand the difference between Shapes (SHACL or OSLC) and Ontologies (OWL).
Worth runnign with the tool to get some hands-on experience. With the tool, you can model both.