> An automation result has 0 or more contributions, which may be of > different types, e.g. logs, downloads (aka artifacts), compilation/ > test/static analysis results, associated SCM artifacts and change > requests, etc. > As such, the basic contribution type will have to be pretty generic, > but specific types of contributions will have more specific > properties. For example, logs and downloads could have a file name, > file size, and a link to their content. We may also want to include > its media type as metadata in the contribution, to avoid having to > fetch the (possibly large) content just to determine the kind of file. > > Are there any recommendations for how best to model this in RDF, in > a way that's consistent with the Core Spec? Should we define > multiple types of contributions in a subtype hieararchy? How should > we handle types that we're not aware of a-priori? How should the > supported properties for each type be described? Have any of the > other specs addressed this kind of issue?
We do have a similar situation in OSLC SCM for containers and their members, and we have addressed it precisely as you suggest, with an abstract super-type (ObjectVersion) and a bunch a sub-types. The SCM spec describes the properties for ObjectVersion, and then for each specific sub-type the spec describes only the additional properties of that subtype. Providers can add their own properties to these types, and can add their own types as well; resource shapes must be supplied for all types, so the client can discover the full set of types and properties. I'm not at all sure we have yet addressed all your questions about the impact of this design on queries! Implementations of SCM are not yet ready, and I suspect we will find we need to tweak several areas of this design. Nick. From: Nick Edgar <[email protected]> To: [email protected] Date: 04/29/2010 11:25 AM Subject: [Oslc-Automation] How to represent contributions of different types Sent by: [email protected] Currently in the prototype implementation in RTC Build, we've defined different types like AutomationResultArtifactContribution and AutomationResultLogContribution and each has separate a collection property in the result. This doesn't actually meet the spec-so-far, since there's no overall oslc_auto:contributions property on the result. It also won't scale well if there are many different types. Having multiple collections also complicates queries, and their description in the service document. I'm thinking of changing this to have a single contributions collection where items are AutomationResultContribution but may also declare themselves as having a more specific type, and providing the corresponding properties. For example: ... <oslc_auto:AutomationResult rdf:about=" http://some_server/oslc/automation/results/some_result_id> ... <oslc_auto:contributions rdf:resource=" http://some_server/oslc/automation/results/some_result_id/contributions"/> </oslc_auto:AutomationResult> And the contributions resource is a query collection of contributions with an additional type declaration and type-specific properties. <rdf:RDF ...> <oslc:Query> ... </oslc:Query> <AutomationResultContribution rdf:about=" http://some_server/oslc/automation/results/some_result_id/contributions/some_contribution_id_1 "> <rdf:type rdf:resource=" http://open-services.net/xmlns/oslc_automation#LogContribution"/> <dc:title>buildLog.txt</dc:title> <oslc_auto:fileSize>13579</oslc_auto:fileSize> <oslc_auto:content> http://some_server/oslc/automation/results/some_result_id/contributions/some_contribution_id_1/content/buildLog.txt </oslc_auto:content> <oslc_auto:contentType>text/plain</oslc_auto:contentType> </AutomationResultContribution> ... </rdf:RDF> By having an additional type, this would allow queries like the following, to return only the log contributions: http://some_server/oslc/automation/results/some_result_id/contributions?oslc.where=rdf:type=oslc_auto:LogContribution I'm wondering if this is a mis-use of rdf:type though. The RDF spec says that its value should be an rdfs:Class resource, which I don't think we're using in OSLC (using resource shapes instead). Should we define our own property instead, e.g. oslc_auto:contributionType? Another issue is that it may be hard to map different kinds of contributions in the various systems to proper type URLs. In RTC Build, the contribution type is an arbitrary string. Although we have a few predefined ones for artifacts, logs and links, clients are free to add contributions of any type they want. Any insight on the above issues would be appreciated. Thanks, Nick_______________________________________________ Oslc-Automation mailing list [email protected] http://open-services.net/mailman/listinfo/oslc-automation_open-services.net
