[oslc-rm] Possible OSLC priorities and themes for 2011

[Dave]

Hello OSLC workgroups and community:

Now that the OSLC v2 specs are finalizing we need think about what are
the next priorities for the OSLC community. Based on feedback from the
the Core workgroup and others, I've put together a list of possible
priorities for us to consider.

Three themes:

1) Adoption of specs: these are things that help folks adopt OSLC,
both users and consumers. This includes tutorials, documentation,
clients, test suites and reference implementations.

2) Guidance on using specs: the development of Guidance on specific
topics needed by one or more OSLC domains, things that can be
accomplished by applying the current specs, RDF and HTTP.

3) New specifications: these are new features that we need in the Core
or domain specs, things that require new specification text to be
developed.

We'd love your feedback. What do you think of the items below? Can you
think of new priorities that can help us with the three themes above?
Are these the correct three themes to address and where should we put
our emphasis as we head into 2011? Please respond here on this email
thread and I'll do my best to capture the results.

Thanks,
Dave


Possible OSLC 2010 - 2011 priorities and themes

---
1) Adoption

Development of existing Test Suites The OSLC Core workgroup is not
going to write code together, but we can play a part in helping to
design test suites, advising teams creating them and possibly
approving or endorsing test suites.

Development Reference implementations The Core is not going to write
an RI either, but we can play a part in helping to design test suites,
advising teams creating them and possibly approving or endorsing test
suites.

---
2) Guidance

Guidance on Attachments In several OSLC domain there are use cases
where some unmodifiable resource, e.g. an uploaded screenshot image,
must be stored and property-values about that resource must be stored
as well, but cannot be added to the resource. There are several
patterns for this, one in AtomPub protocol and one in the OSLC Asset
Management spec and there are others. We should explore the
alternatives, the pros and cons of each and then issue guidance.

Guidance on Hierarchical URLs We need stable and opaque URLs for all
OSLC resources, constraints that seem to rule out embedding any sort
of hierarchy into URLs, but there are cases where hierarchies are
needed, for example in Asset Management, where artifacts may be web
pages and associated CSS or JavaScript resources that reference each
other with relative URLs. We should explore the alternatives, the pros
and cons of each and then issue guidance.

Guidance on Staging URLs We need stable and opaque URLs for all OSLC
resources, constraints that seem to rule out the notion of staging
URLs, but this notion is needed in Asset Management where software
releases "go live" only after all resources are in place. We should
explore the alternatives, the pros and cons of each and then issue
guidance.

Guidance on Multi-topic resources There will be cases where a resource
is of multiple rdf:types and we have no guidance on how this situation
should be handled. The Core workgroup should explore the issue,
understand the issues an issue guidance in this topic.

Guidance on best practices for domain workgroups extending the OSLC Core spec.

---
3) New specifications

Standardization of SPARQL Partial Update Resource update is an
important feature and while PUT works, it can be dangerous and in some
cases inefficient. We need a way to update specific property values of
a resource in a targeted way and we should work with an existing W3C
workgroup, if possible, to address this rather than inventing our own
new protocol.

Standardization of JSON/RDF A growing number of OSLC specifications
require a JSON representation and while we have a simple JSON
representation that can be used to represent OSLC defined resources,
it is non-standard and certainly not perfect. We need a standard way
to represent RDF in JSON and we should work with ongoing efforts at
W3C or other places to help create one.

Seed List or other approach for Distributed Search In integrating
ALM/PLM systems it is useful to be able to crawl and index resources
from across multiple systems and domains. The OSLC Core workgroup
should seek a standard way to enable this, explore alternatives and
create an OSLC Core spec for distributed search/query indexing.

Specification for Eventing In integration of ALM/PLM systems, there is
a need to allow one system to register for events with one system and
then receive notification whenever a build is created, or a new defect
is reported. There are a number of techniques for enabling this
including RSS/Atom feeds, trackbacks and web hooks. We should explore
the alternatives, the pros and cons of each and then create a
specification for OSLC Core Eventing.

Specification for Baselining In integrating ALM/PLM systems, there is
a need to allow resources across multiple systems to be baselined or
"tagged" as part of a product release, integration point or branch
point. We should explore the alternatives, the pros and cons of each
and then create a specification for OSLC Core Baselining.