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

[Nicholas Crossley <nick_crossley@us.ibm.com>]

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
.

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.

Nick.



From:      
 David Honey1 <DavidHoney@uk.ibm.com>
To:      
 oslc-ccm@lists.oasis-open.org
Date:      
 06/03/2016 04:23 AM
Subject:    
   [oslc-ccm] Comments
on Change Management specs
Sent by:    
   <oslc-ccm@lists.oasis-open.org>

---

Comments in this colour...

https://tools.oasis-open.org/version-control/browse/wsvn/oslc-ccm/trunk/specs/change-mgt/change-mgt.html

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

When CM clients request:

• application/rdf+xml CM servers MUST respond with RDF/XML representation without restrictions.
• application/ld+json CM servers MUST respond with JSON-LD representation.
• application/xml CM servers MUST respond with OSLC-defined abbreviated XML representation as defined in the OSLC Core Representations Guidance
• application/atom+xml CM servers MUST respond with Atom Syndication Format XML representation as defined in the OSLC Core Representations Guidance
• The Atom Syndication Format XML representation SHOULD use RDF/XML representation without restrictions for the atom:content entries representing the resource representations.

[David]
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
. 
2.9 Labels for Relationships 

[David]
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. 

https://tools.oasis-open.org/version-control/browse/wsvn/oslc-ccm/trunk/specs/change-mgt/change-mgt-resources.html

[David] 
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. 

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

[David] 
The description of oslc_cm:affectsRequirement
uses 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.

[David] 
The description of oslc_cm:tracksChangeSet
does 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