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

Attendees

• NickCrossley
• ArthurRyman
• ScottBosworth
• IanGreen
• PaulMacMahan?

Topics discussed

Proposed new oslc:InstanceShape description

• Approved new language
• AI: Dave J to edit down to reasonable size for table

Proposed new Service Provider description

Proposed improvement to Range description in Core Spec

• Scott B: make it clear that these are best practices for specifying resource property ranges
• Arhur R: in a recent review of the Core spec, noticed that we specify range of Any in places where we should be specific
• (we looked for examples and found one or two, one being the Creation Factory's oslc:resourceShape property)
• Arthur R: the spec should be more navigable and each range specified should be a real live link
• Scott B: there is an open TODO to clarify the ranges across the Core documents, also agree that spec should be more navigable
• Ian G: also note that there a number of places where links are broken or do not have correct fragment identifiers

Proposed changes to Link Guidance wording on link subject types

• (discussed and approved)

Proposed changes to introduction in Common Properties

• Scott B: make it clear that these are available for use by domain specifications, and that domain specifications are are definitive on this topic of allowed and required links

Namespace URI setup

• (discussed work Scott B has done to set this up)
• (discussed work Arthur R has done to create an RDFS description)
• Scott B: how will resource shapes be linked to?
• Arthur R: using the see also property
• (discussed transforming RDFS into HTML for use in wiki)
• What about the non OSLC defined properties we use in our specs?
• Arthur R: each namespace we defined should be represented by an RDFS document listing the properties defined within
• (resource shapes are per resource use case, RDFS documents are per namespace)
• Arthur R: look to the resource shape for all allowed and required properties for a given resource use case
• Scott B: willing to write this up?
• Arthur R: not yet, still more work to do, creating XSLT transform, etc.