OSLC Core Meeting September 29, 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

Review actions from past week

AI: Steve to propose new description for oslc:instanceShape

oslc:instanceShape: the URI of a Resource Shape that describes the possible properties, occurrence, value types, allowed values and labels. This shape information is useful in displaying the subject resource as well as guiding clients in performing modifications. The subject resource's allowed set of properties MAY NOT be limited to the defined set within this associated shape. Instance shapes MAY be specific to the authenticated user associated with the request that retrieved the resource, the current state of the resource and other factors. Consumers MUST assume that the shape information is valid only in the limited context of the specific request for which was retrieved and is not applicable in other contexts or as a general purpose shape of the resource. Instance shapes SHOULD NOT be cached.

AI: Steve to propose better description in Appendix A for oslc:serviceProvider (cases when there can be > 1)

http://open-services.net/pipermail/oslc-core_open-services.net/2010-September/000572.html

oslc:serviceProvider The scope of a resource is a link to the resource's OSLC Service Provider. There may be cases when the subject resource is available from a service provider that implements multiple domain specifications, which could result in multiple values for this property.

AI: Dave J improve range description in Core spec:

Range (String): for properties with a resource value-type, OSLC specifications should also specify the range of possible resource classes allowed. This can be specifed as any or as a list of one or more resource classes specified by Prefixed Name. Best practices for specifying range are covered in the OSLC Core Links Guidance? document

AI: Dave J improve Link Guidance in light of this discussion

Relationships in OSLC resources are at their simplest an RDF property whose object is a URI. In some cases within one system, it is necessary to require a closed link, i.e. require the object of a link be of one or more specific resource types. In general, it is better to be open like the web and not place restrictions on the type of resource linked to. The property's purpose and name should clearly reflect the scenarios it is supporting. Since the usage of these relationship properties may exist for a long period of time, specification authors should use great care in determining these.

AI: Dave J to explain meaning of Common properties and especially occurs properties

This is a list of common properties and resources that are defined by or used by the Core spec. Unlike the rest of the Core specification, this Appendix will change and grow as new common properties are added by the Core workgroup. The properties that we list here are available for use in defining OSLC resources, but this does not mean that they are required to be in OSLC resources.

Scott B: setup Namespace URIs on open-services.net

http://open-services.net/pipermail/oslc-core_open-services.net/2010-September/000571.html

Minutes

Attendees and notes from the meeting

Possible Attendees

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

Topics discussed

TBD