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


Help: OASIS Mailing Lists Help | MarkMail Help

camp message

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

Subject: [OASIS Issue Tracker] Created: (CAMP-165) CAMP and RDF


                 Key: CAMP-165
                 URL: http://tools.oasis-open.org/issues/browse/CAMP-165
             Project: OASIS Cloud Application Management for Platforms (CAMP) TC
          Issue Type: New Feature
          Components: SPEC PR2
            Reporter: Martin Chapman 


Was any consideration taken in providing an RDF serialization of the CAMP REST data model?

I've seen one mention of it in the minutes [1] in the context of JSON-LD, where JSON-LD was rejected because it is used to represent RDF.

I ask because there are a couple of places where CAMP and OSLC [2] could work together, and OSLC uses RDF and Linked Data. The couple of places that come to mind are:
1. CAMP plans could expose OSLC "Automation Plans" [5] for creating new assemblies from the plan, including using OSLC "delegated UI dialogs" to provide an HTML UI provided by the provider that can be embedded in the consumer's UI [6]
2. CAMP plans and assemblies could be linked to OSLC Change Request tickets [7] that track the request that caused the plan/assembly to be created. (This is possible with any RDF resource)
3. OSLC Actions [3] and CAMP "action" resources look very similar in intent. (OSLC actions are likely to be contributed to the OASIS OSLC Core TC [4])

While I expect it would be possible to write CAMP extensions to enable these sorts of scenarios, if it were possible to represent the CAMP data model in RDF then these things would be possible straight away, due to the namespace-qualified terms in RDF (allowing CAMP, OSLC, etc terms to be mixed in a single resource representation but retaining the semantics defined at their source), the assumption (which is standard in RDF) that any triples (/properties) can be mixed in to any resource, and the provider does not need to understand them to be able to store them (although it cannot do anything with them than make them available to consumers, for the benefit of those consumers who do understand them).

I know this is too late for v1.1, so I'm raising it as a question for consideration for a subsequent version, or for a separate document (e.g. "CAMP data model mapping to RDF") for use by systems that want to be able to link to the Linked Data world, such as OSLC providers.

(If you have any questions about what I'm asking or about the references I've given, feel free to ask me for more detail or clarification.)

Martin Pain

[1] http://markmail.org/search/?q=rdf&q=list%3Aorg.oasis-open.lists.camp#query:rdf%20list%3Aorg.oasis-open.lists.camp+page:1+mid:ojzgsxa6q4hf2fca+state:results
[2] http://www.oasis-oslc.org/
[3] open-services.net/wiki/core/Exposing-arbitrary-actions-on-RDF-resources/
[4] https://www.oasis-open.org/committees/tc_home.php?wg_abbrev=oslc-core
[5] http://open-services.net/wiki/automation/OSLC-Automation-Specification-Version-2.0/#Automation-Resource-Definitions
[6] http://open-services.net/bin/view/Main/OslcCoreSpecification?sortcol=table;table=up#Delegated_User_Interface_Dialogs
[7] http://open-services.net/bin/view/Main/CmSpecificationV2?sortcol=table;up=#CM_Resource_Definitions

This message is automatically generated by JIRA.
If you think it was sent incorrectly contact one of the administrators: http://tools.oasis-open.org/issues/secure/Administrators.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira


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