[Oslc-Automation] How to represent contributions of different types

[Nick Edgar]

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?

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://open-services.net/pipermail/oslc-automation_open-services.net/attachments/20100429/7e0a96cd/attachment-0003.html>