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=59737#comment-59737 ] 

Martin Pain  commented on OSLCCORE-20:

To me a representation is always a description. Or, to put it the other way, a description is a representation not a resource. (I accept that in complex cases a separate description resource can help). In the specific case of a container you are right that you could describe it in terms of its contents (e.g. list of change requests) or in terms of itself (e.g. using the ServiceProvider resource shape).

As an aside, in many cases I wouldn't see a project area as a container of things like change requests. Just as a ServiceProvder links to Services, I would see a project area as containing one container of change requests, one container of configuration management streams, another container of configuration management components, etc. Well, for a multi-domain solution anyway.

If a server has a "native" representation of its project areas (e.g. using POX or JSON), then using content negotiation to request either the native representation (that presumably focuses mostly on content, but will describe the container itself too - e.g. including project display name) or the OSLC RDF/XML or Turtle one (which can describe the content and/or the more detailed OSLC-shaped description) seems correct - two different ways of representing/describing the same resource.

If the server natively uses RDF, then it's easy to mix two vocabularies describing the same resource. (And LDP provides a precedent for restricting which profile/vocabulary of RDF you want in the response - although we might want to think about what restrictions we put on default behaviour).

So for a server whose project areas/service providers serve a single domain, and they have a native RDF vocabulary to describe the project areas, and they wanted a tight coupling between the service provider concept and the project area concept (such that you could find a service provider for a given project area) then it could look something like this:

   rdf:type oslc:ServiceProvder, oslc:Service, ex:ProjectArea;
   dcterms:title "My project area";
   oslc:service: <>;
   oslc:domain: <http://open-services.net/ns/cm#>;
   # And creation factories, query capabilities, dialogs, etc
   # And any other properties required by the native RDF vocabulary

And if they already have separate URLs for the two resources, we could look into whether owl:sameAs would be appropriate to link the two (but I know there are problems with that).

Although, on the other hand, we could give the server implementors the option to treat them as separate resources. oslc:details would be one existing property that we could consider, although that should be to a URL that's meaningful for requesting in a browser. There's also rdfs:seeAlso.

> 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
> 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]