[OASIS Issue Tracker] (OSLCCORE-20) Service provider should describe domain/scope

[OASIS Issues Tracker <workgroup_mailer@lists.oasis-open.org>]

    [ https://issues.oasis-open.org/browse/OSLCCORE-20?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=60564#comment-60564 ] 

Martin Pain commented on OSLCCORE-20:
-------------------------------------

My understanding of the David's proposal is (using the terminology from Jim's comment on 18th Aug):
1. Resource Service Provider has an oslc:details property whose value is a URI of a resource (R) about which the service provides services (not details). That is, the service provider IS the "Resource Descriptor" (RD) of some resource (R).
2. HTML and RDF/XML must be supported and Turtle should be supported representations of R.

Therefore, to address Jim's issues:
1.
a) "For OSLC3, if the resource R has discoverable capabilities (and is of type Service Provider, see https://issues.oasis-open.org/browse/OSLCCORE-23), then it is an LDPC and the client already has access to the service provider resource using a GET to get the properties, or OPTIONS to get the Link headers. Setting olsc:details in this case seems redundant." - I agree
b) OSLC3 servers might not want to make their existing vendor-specific resources OSLC resources. (Personally I believe that it is very much best practice to make existing RDF resources OSLC resources - that in this case OSLC discovery is "annotation" that can be layered over existing resources. But I know others might disagree, and it may well be easier to implement as a separate API.) In this case, they want a link between their vendor-specific resource and their OSLC3 SP. Knowing the URI of the vendor-specific resource, they can look at the SPs and find one that has oslc:details pointing to that URI. They know that is the SP they are looking for. (No need to compare dcterms:title properties).

2. "OSLC2 already has ServiceProvider dcterms:title which for RTC is the project area name. Why not require this title to match the title of the resource the ServiceProvider is describing?" If the client is an automated/unattended process, then I suggest they use the URI of the partition/project area (as 1b above). If they are a human, then yes I would agree it is the SP's title they should be looking at, and that ought to match the other resource (project area).

3. "What if resource R doesn't have a dcterms:title? Wouldn't it be more useful to have the descriptor contain a property that is the URL of R itself, not its title?" See 1b above.

4. "Similar to Compact and Dialog, wouldn't we need to define a vocabulary term and constraining shape for this descriptor resource?" N/A because I don't see it as a descriptor resource.

> Service provider should describe domain/scope
> ---------------------------------------------
>
>                 Key: OSLCCORE-20
>                 URL: https://issues.oasis-open.org/browse/OSLCCORE-20
>             Project: OASIS OSLC Lifecycle Integration Core (OSLC Core) TC
>          Issue Type: Improvement
>            Reporter: David Honey
>            Assignee: James Amsden
>              Labels: ready-for-vote
>
> OSLC 2.0 supports a service declaring a domain or scope using oslc:domain and oslc:usage. Jazz applications frequently declare a service provider for each project area. However, there is no standard way for a client to determine which service provider to use for a known project area.



--
This message was sent by Atlassian JIRA
(v6.2.2#6258)