oslc-core message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: Re: [oslc-core] OSLCCORE-35: v2 Resource Shape oslc:Inline property incorreclty mentions blank nodes
- From: Martin P Pain <martinpain@uk.ibm.com>
- To: "Jim Amsden" <jamsden@us.ibm.com>
- Date: Thu, 3 Sep 2015 13:34:38 +0100
I wouldn't be surprised if the original
authors were having difficulty separating RDF/XML and the underlying triples
(that is, the RDF) in their minds (not necessarily through lack of knowledge).
I haven't read anything that explicitly talked about constraining the RDF/XML
representation to force the elements to be inline, so I agree with Arthur
& Nick on that one (although I haven't seen Arthur's comment, but only
Nick's reference to it).
Jim, I don't really understand the rest
of your email (I only have time to scan it quickly) - does it match with
the table in Nick's email?
Martin
Pain
Software Developer - Green Hat
Rational Test Virtualization Server, Rational Test Control Panel |
IBM United Kingdom Limited Registered in
England and Wales with number 741598 Registered office: PO Box 41, North
Harbour, Portsmouth, Hants. PO6 3AU
From:
"Jim Amsden"
<jamsden@us.ibm.com>
To:
OASIS <oslc-core@lists.oasis-open.org>
Date:
02/09/2015 20:11
Subject:
Re: [oslc-core]
OSLCCORE-35: v2 Resource Shape oslc:Inline property incorreclty mentions
blank nodes
Sent by:
<oslc-core@lists.oasis-open.org>
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 |
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
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]