OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

oslc-ccm message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: Re: [oslc-ccm] Comments on Change Management specs

Nick and David,
Thanks for the review. Comments embedded below in <jra>tags.

On the use of foaf:Person, etc., for Configuration Management the Turtle we currently use for properties such as dcterms:creator is the following:

   oslc:range               foaf:Person, foaf:Agent ;

   dcterms:description      """Creator or creators of resource.

The link target is usually a <code>foaf:Person</code> or <code>foaf:Agent</code>, but could be any type."""^^rdf:XMLLiteral .

<jra>In OSLC Core TC, we agreed to stick with just foaf:Person with the description indicating other types could be used. So there doesn't seem to be a lot of motivation for listing multiple types.</jra>

On the topic of the range for oslc_cm:tracksChangeSet: in earlier drafts, we probably mentioned oslc_scm:ChangeSet. We removed that from the draft when OSLC SCM was deprecated, but there are probably implementations around that still use the old OSLC SCM types.  Of course, we have made the oslc:range field permissive, so specifying oslc_config:ChangeSet as the range for tracksChangeSet would not prevent use of other types defined in OSLC SCM or elsewhere.

<jra>There are currently no references to oslc_scm in the shapes. Should we add that back for compatibility purposes? Or is the loose interpretation of range sufficient?</jra>

David's Comments in this colour...


CM servers MUST provide Turtle and JSON-LD, and MAY provide RDF/XML, XML, and Atom Syndication Format XML representations.

When CM clients request:

These two sections are contradictory. For example, if a server does not support RDF/XML, then it should be acceptable for the CM server to return 406 Not Acceptable. This is standard HTTP content negotiation, so I'm not sure I understand the purpose of the bulleted section. Also, an ACcept header can specify multiple acceptable media types with weighting. So the bullet points are not necessarily mutually exclusive. A client might perform a GET with both text/turtle and application/rdf+xml being acceptable, and it's up to the server which of the two media types to provide in the response


<jra>This is an incomplete change resulting from enforcing backward compatibility. Turtle and JSON-LD were MUST because of LDP. The sub-bullets are necessary for compatibility with OSLC v2.0. So I'll update the first line to make it consistent. This now reads:

CM servers MUST provide Turtle and JSON-LD, SHOULDprovide RDF/XML, XML, and MAY provide Atom Syndication Format XML representations.

When CM clients request:


2.9 Labels for Relationships

This section seems bizarre to me. We already provide a standard mechanism, resource shapes, for defining labels for links. Why invent yet another way of doing so? I thought that OSLC, in general terms, shunned the use of reification.

<jra>This approach was defined in CM 2.0 and was retained for compatibility. I don't know the history, but my understanding is that this was intended to provide a server option for labels on property values for servers that don't support resource preview. Do we know if there are any instances where servers do this? Should this section be removed, or does it need to be retained for backward compatibility? Note that this section is non-normative guidance. Minor update:



I was expecting some for of class hierarchy, where there was a class used as the superclass that defined the common properties, and then subclasses for Defect, Enhancement etc that added their type-specific properties. The current presentation makes it difficult to check for consistency where a property is described for more than one class.

<jra>I'll add a UML diagram for this</jra>


For properties like dcterms:creator, I thought we discussed this in OSLC core and decided it should mention foaf:Agent rather than foaf:Person?

<jra>For Core we decided to stick with foaf:Person, but added the loose meaning of oslc:range</jra>


The description of
oslc_cm:affectsRequirementuses a full URI whereas elsewhere a QName is used. I think we should be consistent and use oslc_rm:Requirement. Same comment for oslc_cm:implementsRequirement and oslc_cm:tracksRequirement.
<jra>Fixed, the oslc_rm namespace prefix wasn't defined.</jra>


The description of
oslc_cm:tracksChangeSetdoes not specify the type of target resource. Now that we have an oslc_config:ChangeSet type, should this be mentioned for this property?

Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number 741598.
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]