Re: [oslc-core] OSLCCORE-35: v2 Resource Shape oslc:Inline property incorreclty mentions blank nodes

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

Martin,
I had assumed, perhaps mistakenly, that
oslc:Inline meant not only that the properties of the referenced resource
needed to be in the same resource representation, but that they had to
be inlined in the RDF representation the referenced object. 

For example:

<oslc:ServiceProvider rdf:about="https://oslclnx2.rtp.raleigh.ibm.com:9443/ccm/oslc/contexts/_pMhMgPsWEeSnQvDHoYok5w/workitems/services.xml">
    <dcterms:title rdf:parseType="Literal">JKE
Banking (Change Management)</dcterms:title>
    <oslc:details rdf:resource="https://oslclnx2.rtp.raleigh.ibm.com:9443/ccm/process/project-areas/_pMhMgPsWEeSnQvDHoYok5w"/>
    <dcterms:publisher>
      <oslc:Publisher>
        <dcterms:title
rdf:parseType="Literal">IBM Rational Team Concert Work Items</dcterms:title>
        <dcterms:identifier>com.ibm.team.workitem</dcterms:identifier>
        <oslc:icon
rdf:resource="https://oslclnx2.rtp.raleigh.ibm.com:9443/ccm/web/com.ibm.team.rtc.web/ui/graphics/UICustomizations/RationalTeamConcert.ico"/>
      </oslc:Publisher>
    </dcterms:publisher>

    <oslc:service>
      <oslc:Service>
        <oslc:domain
rdf:resource="http://open-services.net/ns/cm#"/>
        <oslc:creationFactory>
          <oslc:CreationFactory>
           
<dcterms:title rdf:parseType="Literal">Location for creation
of Defect change requests </dcterms:title>
           
<oslc:usage rdf:resource="http://open-services.net/ns/core#default"/>
           
<oslc:usage rdf:resource="http://open-services.net/ns/cm#defect"/>
           
<oslc:resourceType rdf:resource="http://open-services.net/ns/cm#ChangeRequest"/>
           
<oslc:resourceType rdf:resource="https://oslclnx2.rtp.raleigh.ibm.com:9443/ccm/oslc/types/_pMhMgPsWEeSnQvDHoYok5w/defect"/>
           
<oslc:resourceShape rdf:resource="https://oslclnx2.rtp.raleigh.ibm.com:9443/ccm/oslc/context/_pMhMgPsWEeSnQvDHoYok5w/shapes/workitems/defect"/>
           
<oslc:creation rdf:resource="https://oslclnx2.rtp.raleigh.ibm.com:9443/ccm/oslc/contexts/_pMhMgPsWEeSnQvDHoYok5w/workitems/defect"/>
          </oslc:CreationFactory>
        </oslc:creationFactory>
      </oslc:Service>
    </oslc:service>
  </oslc:ServiceProvider>

not:

 <rdf:Description rdf:about="https://oslclnx2.rtp.raleigh.ibm.com:9443/ccm/oslc/contexts/_pMhMgPsWEeSnQvDHoYok5w/workitems/services.xml">
    <dcterms:publisher
rdf:nodeID="A33"/>
    <oslc:service rdf:nodeID="A31"/>
    <rdf:type rdf:resource="http://open-services.net/ns/core#ServiceProvider"/>
    <dcterms:title rdf:parseType="Literal">JKE
Banking (Change Management)</dcterms:title>
    <oslc:details rdf:resource="https://oslclnx2.rtp.raleigh.ibm.com:9443/ccm/process/project-areas/_pMhMgPsWEeSnQvDHoYok5w"/>
    <oslc:service rdf:nodeID="A1"/>
    <jfs_proc:consumerRegistry
rdf:resource="https://oslclnx2.rtp.raleigh.ibm.com:9443/ccm/process/project-areas/_pMhMgPsWEeSnQvDHoYok5w/links"/>
  </rdf:Description>

  <rdf:Description rdf:nodeID="A31">
    <oslc:selectionDialog
rdf:nodeID="A32"/>
    <calm:home rdf:nodeID="A30"/>
    <oslc:domain rdf:resource="http://open-services.net/ns/cm-x#"/>
    <rdf:type rdf:resource="http://open-services.net/ns/core#Service"/>
  </rdf:Description>

   <rdf:Description rdf:nodeID="A31">
    <oslc:selectionDialog
rdf:nodeID="A32"/>
    <calm:home rdf:nodeID="A30"/>
    <oslc:domain rdf:resource="http://open-services.net/ns/cm-x#"/>
    <rdf:type rdf:resource="http://open-services.net/ns/core#Service"/>
  </rdf:Description>

That is, tools that wish to use XPath
or JQuery on XML DOM could rely on a specific format of the resource to
extract specific information.

Assuming that's not the case (even thought
it may be a common practice), that either of the above are considered valid
osl:Inlined for oslc:representation, then it seems the only motivation
for saying the value type is oslc:LocalResource is to reenforce the idea
that the content has to be in the same resource, and either inlined RDF/XML
object values or blank node references would be valid representations of
the inlined content.

Regarding the values of objects in assertions
in an RDF resource, I don't any reason the value of an object can't be
a URI and a reference to something in the resource representation at the
same time - whether its an absolute URI in an rdf:about or a relative URI
in an rdf:ID. An RDF parser would just treat that as a subject predicate
object assertion with the object value being a URI whose value is also
a subject URI in the same resource representation.  This would simply
control whether the subject resource could be accessed separately on its
own as well as obtained as a local resource.


Jim Amsden, Senior Technical Staff Member
OSLC and Linked Lifecycle Data
919-525-6575




From:      
 Martin P Pain <martinpain@uk.ibm.com>
To:      
 OASIS <oslc-core@lists.oasis-open.org>
Date:      
 09/02/2015 12:57 PM
Subject:    
   [oslc-core]
OSLCCORE-35: v2 Resource Shape oslc:Inline property incorreclty mentions
blank nodes
Sent by:    
   <oslc-core@lists.oasis-open.org>

---

While looking at the tables in OSLC
v2 for the discovery resources (which use resource shape terminology, in
particular the "valueType" and "representation" columns)
I realised that the vocab file's definition of oslc:Inline does not seem
correct. 

For more info see the JIRA I raised: https://issues.oasis-open.org/browse/OSLCCORE-35

This has also raised the question in my mind as to whether most of the
places in the v2 spec (or at least the discovery part) that say oslc:LocalResource
for the "value type" (which requires use of a blank node - an
RDF resource without a URI) ought to say oslc:AnyResource for "value
type" and oslc:Inline for "representation" - the only difference
(as far as I'm aware) is that the latter allows the resources to have a
URI (which may or may not be a hash URI) - but still requires their representation
to be inlined. I can't see any benefit to either clients or servers of
requiring a blank node. I also don't think that would be a backwards-incompatible
change, as clients who can deal with blank nodes should be able to deal
with inlined representations (it's making the change the other way round
that might break clients). 

Any thoughts on either the vocab or the spec? I wouldn't be surprised if
I've missed something.

Martin Pain
Software Developer - Green Hat
Rational Test Virtualization Server, Rational Test Control Panel

E-mail:martinpain@uk.ibm.com Find me on:  and within IBM on:

IBM United Kingdom Limited Registered in England and Wales with number
741598 Registered office: PO Box 41, North Harbour, Portsmouth, Hants.
PO6 3AU 
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