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

["Jim Amsden" <jamsden@us.ibm.com>]

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>
Nick. 


David's 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 SHOULDuse 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
. 
<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:

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

</jra>

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. 
<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:

• The property: OSLC recommends using the rdfs:label property of the rdf:Property from the vocabulary to display the property.
• The value, or object of the triple: OSLC recommends using OSLC resource preview [OSLCResourcePreview] to obtain an appropriate icon and label, and possibly a small and/or large dialog for displaying the object.
• The link: The link is a combination of the subject, predicate and object of the triple (RDF statement or assertion). In the case where the link requires a unique label that is not available from the target resource, only then OSLC servers may support a dcterms:title on a reified statement to provide a label for a link that describes the assertion itself.

</jra>


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. 
<jra>I'll add
a UML diagram for this</jra>

[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?
<jra>For Core
we decided to stick with foaf:Person, but added the loose meaning of oslc:range</jra>

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

[David] 
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? 
<jra>Fixed</jra>


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