OSLC/Lyo Questions

[jad]

Hi @fritter,

What is producing the 404 exception to a sparql request?

Now I try to answer your questions

1.

yes, Lyo is still based on OSLC 2.0, and 3.0 should be backward compatible with 2.0.
And yes, in both specs ServiceProvider and a ServiceProviderCatalog are not mandatory (most things in the OSLC specs are not mandatory. But your implementation should implement them if you find the features necessary).
Note that ServiceProvider and a ServiceProviderCatalog are defined as Containers in 3.0.

2.
WebService & Service are the terms LyoDesigner uses in its interface. Only the latter - Service - is defined in the specs.
Service corresponds to that you see in the specs (See for example the figure OSLC Core Version 3.0. Part 2: Discovery), which then contains references to QueryCapability, CreationFactory, etc. The Service itself is contained within a ServiceProvider.
I believe your point 6 below relates to this question too,

Now, WebService defines the C.R.U.D. methods on resources to handle a specific resource with a given URL. Note that these C.R.U.D. methods are not part of the OSLC Service (See the figure I just referenced). and that’s why LyoDesigner lets you model them separately.

When you model a Service, you need to define the query/creation capabilities and they have a property that specify the URL of that service. (queryBase, or creation)
For a particular resource, you already know the URL of that resource, so you can then simply call GET/PUT/DELETE on it.

This older thread might be of some help too

Why Doesn't OSLC Fully Comply with Roy Fielding's HTTP Semantics?

Hi Mario, My confusion is not really on the methods and how they are implemented in OSLC, but rather how they are implemented with respect to a particular path. Given /foo/{id}, per Fielding: GET on /foo returns all foo objects. A set of query string parameters can be used to filter the underlying data set. GET on /foo/{id} returns the foo with the given id. DELETE on /foo/{id} deletes the foo with the given id POST on /foo updates a foo, the underlying semantics (create a new one? update i…

3.
I did indeed use some java code to translate from the EMF meta-model of Sysml to define the OSLC shapes (and hence the resulting code). I have not made this code public. I am not sure what I will do with this code. Is the resulting classes insufficient?

4.
The current Sysml implementation does not make use of oslc.properties. I believe the Lyo SDK does support it, but I have not had much use of it recently. so I can’t think of examples. Hope someone else can give better tips.

5.
Both Bugzilla and Sysml support ServiceProviders. Sysml has one for each commit. For Bugzilla, you should have one for each Project.
Here’s for example a link to the Sysml ServiceProviderCatalog
http://sysml2-oslc-dev.intercax.com:8080/sysml_oslc_server/oslc/catalog/singleton.
As you can see, the link on that page is that for its - only - ServiceProvider. Do a GET on that to get more info about the ServiceProvider.

6.
Was figure 1 of any help?
I view a ServiceProvider as the context for your Services.
If you take Bugzilla (or Jira) as an example, you cannot simply create an Issue/changeRequest on a global level. You create an Issue/ChangeRequest/Bug in the context of a specific Project. Each Project hence correspond to an OSLC ServiceProvider. And for each ServiceProvider/Project, you will then get a specific URL to create an Issue/ChangeRequest/Bug within it. That’s the value of the oslc:creation value of the CreationFactory object in fgure 1. Simlarly, if you want to search within the context of a project/ServiceProvider, you use the URL defined in hte oslc:queryBase of a QueryCapability.
A Service is nothing but a container of all the capabilites of a ServiceProvider/Project.

Hope this helps to get you started, and hope you find OSLC of value to your project.