[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 edited comment on OSLCCORE-20 at 8/18/15 6:34 PM:
---------------------------------------------------------------
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 title of the resource the ServiceProvider is describing?
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?
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.
was (Author: jamsden):
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
(v6.2.2#6258)
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]