OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

oslc-core message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

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

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

James Amsden commented on OSLCCORE-20:

Maybe I'm not understanding the proposal:

"A URL of a resource that MUST provide additional information about the service provider. HTML media types MUST be supported. application/rdf+xml MUST be supported. text/turtle SHOULD be supported. The RDF representation of the resource MUST include one dcterms:title statement and one or more rdf:type statements." 

Taking each of these clauses in this proposal:
1. Resource Service Provider has an oslc:details property whose value is a URI of a resource that provides details about the service provider, say a "Resource Descriptor" (RD) of some resource (R).
2. HTML and RDF/XML must be supported and Turtle should be supported representations of RD.
3. If the representation is RDF/XML, then RD must contain on dcterms:title and one or more rdf:type statements. 4. Don't we need a constraint that the dcterms:title in RD would have to be the same as the title of resource R being described?

The original use case was if a user had a URL for some resource R that provided OSLC services, then there needed to be a way to find the Service Provider that describes those services.  The proposed solution solves that problem by having ServiceProvider oslc:details point to a descriptor resource that contains a dcterms:title that can be matched against the dcterms:title of the  resource R.

Is that correct? Is that how the oslc:details would be used?

If so, then there seem to be some issues:
1. 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 - hence this looks like a proposal for OSLC2, not OSLC3.

2. OSLC2 already has ServiceProvider dcterms:title which for RTC is the project area name. Why not require this title to match the 

3. What if resource R doesn't have a dcterms:title?

4. Similar to Compact and Dialog, wouldn't we need to define a vocabulary term and constraining shape for this descriptor resource?

Sorry for being dense, I'm tying to understand why this is a problem for OSLC3, exactly what we are proposing, and how it solves the problem.

> 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

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]