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

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.


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


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


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.



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.


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


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.


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

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