RE: [oslc-core] Review of OSLC Discovery

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

Jad,
Perhaps this table Nick created would
be helpful:

	Representation
Value Type	Reference	Inline	Either
Resource Represents an IRI	A link to an RDF resource with a stable URI. The target RDF resource SHOULD NOT contained within the same RDF graph or same http resource as the source resource; a client may expect to be able to GET this URI separately and independently from the source URI (and possibly PUT/POST to it).	A link to an RDF resource with a stable URI, which might be a hash URI. The target MUST be contained within the same RDF graph or same http resource as the source resource.	A link to an RDF resource with a stable URI, which might be a hash URI. The target RDF resource MAY be contained in the same graph or http resource as the source, so the GET of the source URI might also fetch the target resource.
LocalResource Represents a blank node	n/a	A link to an RDF resource with or blank node, The target MUST be a blank node within the same RDF graph or same http resource as the source resource. Clients MUST assume the resource is not separately fetchable or modifiable.	n/a
AnyResource Represents either an IRI or blank node	n/a	A link to an RDF resource. The target MUST be contained within the same RDF graph or same http resource as the source resource. Clients MUST NOT make any assumptions about the nature of the URI for this resource.	A link to a resource. The representation and location of the target is not defined. Clients MUST NOT make any assumptions about the nature of the URI for this resource.

So as you can see, if the valueType
is specified to be LocalResource, the Representation must be InLine, its
the only one that makes sense. 

What we decided is using LocalResource
was too restrictive, and all references to oslc:LocalResouce in the shapes
were changed to oslc:AnyResouce so servers have flexibility.  

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




From:      
 Jad El-Khoury <jad@kth.se>
To:      
 Jim Amsden/Raleigh/IBM@IBMUS
Cc:      
 "oslc-core@lists.oasis-open.org"
<oslc-core@lists.oasis-open.org>
Date:      
 02/17/2016 02:21 PM
Subject:    
   RE: [oslc-core]
Review of OSLC Discovery
Sent by:    
   <oslc-core@lists.oasis-open.org>

---

Hi
Jim,
 
Things are getting clear,
but I have still have some doubts with stating that a Service resource
can be both a Local resource as well as a LDPC. 
 
In your feedback, you say
that “Local resource is about the representation of the content, not necessarily
its URIs. The shape constraint for ServiceProvider just indicates the Service
resources’ properties must also be included in the representation of the
ServiceProvider - it doesn’t require them to be blank nodes or have fragment
URIs within that representation”.
 
But in the Resource Shape
specs (https://tools.oasis-open.org/version-control/svn/oslc-core/trunk/specs/resource-shape.html),
it is clearly stated that for a oslc:LocalResource, “The object resource
MUST be identified with a blank node.”
 
And, when you say above “Local
resource is about the representation of the content”, this sounds more
like about the Representation being “inline”, rather than the value-type
being LocalResource?
 
When it comes to the constraints
of the ServiceProvider resource, the oslc:service property is currently
constraint to:
representation: inline àThis agrees with your description
value-type: AnyResource àThis means it can also be an oslc:LocalResource, which MUST be a blank
node.
 
Would representation: inline
& value-type: Resource be more appropriate?
 
I may be over-interpreting
the text, and this could stem from the usual confusion I have between Representation
and Value-type. But I‘ll try one last time …
 
regards
______________________________
Jad El-khoury, PhD
KTH Royal Institute of Technology
School of Industrial Engineering
and Management, Mechatronics Division
Brinellvägen 83, SE-100 44
Stockholm, Sweden
Phone: +46(0)8 790 6877 Mobile:
+46(0)70 773 93 45
jad@kth.se,
www.kth.se
 
From: oslc-core@lists.oasis-open.org
[mailto:oslc-core@lists.oasis-open.org]
On Behalf Of Jim Amsden
Sent: 12 February 2016 18:33
To: Jad El-Khoury
Cc: oslc-core@lists.oasis-open.org
Subject: Re: [oslc-core] Review of OSLC Discovery
 
Jad,
Thanks for the review. Comments embedded in the attached document.

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




From:        Jad El-Khoury
<jad@kth.se>
To:        "oslc-core@lists.oasis-open.org"
<oslc-core@lists.oasis-open.org>
Date:        02/11/2016
04:23 PM
Subject:        [oslc-core]
Review of OSLC Discovery
Sent by:        <oslc-core@lists.oasis-open.org>

---

Hi,
 
I read through Discovery, and I just have a couple of questions (&
some minor comments). Please see attached.
 
Most likely, this stems from my confusion with the relationship between
OSLC2.0 resources and LDPC. It mainly relates to the Service and CreationFactory
resources. But might as well double-check if I got it right.
 
regards
______________________________
Jad El-khoury, PhD
KTH Royal Institute of Technology
School of Industrial Engineering and Management, Mechatronics Division
Brinellvägen 83, SE-100 44 Stockholm, Sweden
Phone: +46(0)8 790 6877 Mobile: +46(0)70 773 93 45
jad@kth.se,
www.kth.se
 [attachment "OSLC Discovery.pdf"
deleted by Jim Amsden/Raleigh/IBM] 
---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that 
generates this mail.  Follow this link to all your TCs in OASIS at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php