OSLC Core Meeting September 22, 2010

Last week's meeting

Meeting logistics

See the OslcCoreMeetings for more information, more dial-in numbers and on-line meeting information.

• Conference Access
  • Toll free: 1-866-423-8350
  • Toll: 1-719-387-8273
• Participant passcode: 558663

Agenda

• What do you get when you dereference an OSLC defined rdf:type URI?

• From Steve S: Clarification around the "Range" column for relationship properties. It would be good to add a SHOULD for these and add a description that clients should expect anything.

• From Steve S: There are a number of issues still listed as OPEN at on the Core issues page. I think these are really resolved/closed or deferred but would be good to confirm. Maybe this doesn't need to be on the agenda, only if any open item. need to be discussed. http://open-services.net/bin/view/Main/OslcCoreV2Issues

• Review OSLC Core Next Topics document below. This purpose of this list is to spark conversations on next topics, encourage feedback on the items we have and items we may have left off of the list. Once we're happy with it, we should circulate it in the domain workgroups and among interested colleagues.

• OSLC Core Next Topics:
  • 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 with the existing W3C SPARQL Update Protocol workgroup 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.
  • 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.
  • Seed List 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.
  • 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.
  • 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.
  • 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.

Minutes

Attendees and notes from the meeting

Attendees

• MikeLoeffler
• NickCrossley
• ArthurRyman
• JimConallen
• ScottBosworth
• SteveSpeicher

Regrets:

• IanGreen

Topics discussed

Dave J: What do you get when you get an rdf:type or Property Definitions

• Arthur R: follow W3C? best practices, use content negotiation to return appropriate content, HTML or RDF
• Dave J: not in spec now, when do we need it
• Steve S: for HTML requests, we can redirect to HTML page of appropriate spec
• Scott B: not too late to do this in core spec
• Jim C: which version of spec definition do you get back?
• Arthur R: this is really information about the namespace URIs themselves
• Arthur R: if we are using Apache then we can do content negotiation
• AI: Steve to craft OSLC-CM spec changes
• AI: Steve to document convention for namepace URI

Dave J: re: Clarification around the "Range" - where do we warn about Range, Steve?

• Steve S: when we introduce the Range column
• Scott B: For resource properties that point to resources that may be outside a domain, they should always be Any Resource
• Arthur R: for domain defined resources with internal constructs, we need to be specific about range
• Scott B: we should review the domain specs carefully with this in mind
• Arthur R: add to guidance words about linking to resources in other applications
• AI: Steve review the domain specs to bring them inline with guidance on links
• AI: Dave improve range description in Core spec
• AI: Dave improve Link Guidance in light of this discussion

Dave J: there are still some open pre-Finalization issues OPEN on the Core page:

• AI: Dave to follow up on first issue
• AI: Arthur to follow up on second
• AI: Dave to handle the rest

Dave J: and some real finalization issues

• Dave J: we need to clarify oslc:instanceShape and I'll have a proposal soon
• Dave J: we should make dcterms:identifier and dcterms:title Occurs = unspecified
• Scott B: can we instead add clarification that explains the purpose of common properties?
• Scott B: concerned about shape resource definition, those properties are different and need concrete definitions
• AI: Dave to explain meaning of Common properties and especially occurs properties