This wiki is locked. Future workgroup activity and specification development must take place at
our new wiki
. For more information, see
this blog post about the new governance model
and
this post about changes to the website
.
TWiki
>
Main Web
>
OslcCoreMeetings20100929
(22 Oct 2010,
DaveJohnson
)
(raw view)
---+ OSLC Core Meeting September 29, 2010 [[OslcCoreMeetings20100922][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* <blockquote style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 40px; border-width: initial; border-color: initial; border-style: none; padding: 0px"> =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. </blockquote> *AI: Steve to propose better description in Appendix A for oslc:serviceProvider (cases when there can be > 1)* <blockquote style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 40px; border-width: initial; border-color: initial; border-style: none; padding: 0px"> [[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. </blockquote> *AI: Dave J improve range description in Core spec:* <blockquote> *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. %GREEN%Best practices for specifying range are covered in the [[OslcCoreSpecAppendixLinks][OSLC Core Links Guidance]] document %ENDCOLOR%</blockquote> <br /> *AI: Dave J improve Link Guidance in light of this discussion* <blockquote>Relationships in OSLC resources are at their simplest an RDF property whose object is a URI. %GREEN%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%ENDCOLOR%. 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.</blockquote> <br /> *AI: Dave J to explain meaning of Common properties and especially occurs properties* <blockquote>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. %GREEN% 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.%ENDCOLOR%</blockquote> *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.
E
dit
|
A
ttach
|
P
rint version
|
H
istory
: r4
<
r3
<
r2
<
r1
|
B
acklinks
|
V
iew topic
|
Ra
w
edit
|
M
ore topic actions
Topic revision: r4 - 22 Oct 2010 - 18:39:20 -
DaveJohnson
Main
Main Web
Create New Topic
Index
Search
Changes
Notifications
RSS Feed
Statistics
Preferences
Webs
Main
Sandbox
TWiki
Български
Cesky
Dansk
Deutsch
English
Español
Français
Italiano
日本語
Nederlands
Polski
Português
Русский
Svenska
简体中文
簡體中文
Copyright � by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Contributions are governed by our
Terms of Use
Ideas, requests, problems regarding this site?
Send feedback