[oslc-core] Oslc-Core Digest, Vol 11, Issue 24
Martin Nally
nally at us.ibm.com
Thu Dec 16 14:06:44 EST 2010
Great questions. Here are some thoughts:
Clients will typically be coded with knowledge of a particular version
(or some small number of versions) of some number of OSLC domain specs.
The ideal number of domain specs of which a client has knowledge is 1.
For example, it only tries to interpret test-cases and treats all
related resources as black boxes. Some clients will try to combine
knowledge of more than 1 domain in order to combine information from
multiple heterogeneous resources on a single "page".
If a client has knowledge of OSLC domain XXX at version n, and it lands
on a resource that has an RDF representation that shows an rdf:type that
is defined in OSLC domain XXX, then it is reasonable for the client to
try to interpret the resource according to the spec level it knows.
An ideal client will not assume that a particular property MUST exist,
because a property that was mandated in some version of a spec may not
have existed in a previous version, or could be deprecated in a future
version.
Clients should not assume that all the resources managed by a service
will be at the same version level. A single service may contain
resources from OSLc domain XXX at multiple different specification
levels, with different properties. Version level is a resource
characteristic, not a service characteristic, and services are not
required to "up-convert" older resources to new spec levels.
A client can assume that no predicate will ever change in meaning. If a
predicate means one thing in one version of a spec, it will always have
the same meaning in all versions of the spec.
Clients that use PUT to do updates have to try to maintain all triples
they retrieved on a GET, but do not understand and cannot interpret. A
much better client strategy is to never use PUT for update. Smart
clients will only ever use PATCH for update and will only use PATCH to
update the values of predicates they understand. It is then the server's
responsibility to preserve the values of other predicates. This is why
relational databases have no equivalent of PUT, they only have PATCH.
If a you follow the "validatesRequirement" link from a test case to some
resource, then that resource is a requirement by definition. Even if it
turns out that its a PDF document with no RDF representation, it is
still a requirement. It might not be the form of requirement you were
hoping form but it is a requirement. This is how RDF and the web work.
These are opinions open to debate, of course.
Best regards, Martin
Martin Nally, IBM Fellow
CTO and VP, IBM Rational
tel: +1 (714)472-2690
James Conallen/Philadelphia/IBM wrote on 12/16/2010 01:29:51 PM:
> [image removed]
>
> Re: [oslc-core] Oslc-Core Digest, Vol 11, Issue 24
>
> James Conallen
>
> to:
>
> Martin Nally
>
> 12/16/2010 01:30 PM
>
> Cc:
>
> oslc-core, oslc-core-bounces, Arthur Ryman
>
> I think that we do need to set the expectation that clients
> following a reference from one resource in domain A, to another
> resource there should be no guarantee that the resource adheres to
> any specification. I remember making a request to explicitly include
> verbiage in the core to indicate such.
>
> However I think the point that I was concerned with here is can a
> client that receives a resource that has a property indicating that
> it is of a type (rdf:type) that happens to be defined by an OSLC spec
(i.e.
> http://open-services.net/ns/{somedomain}#{{somedefinedresource}),
> expect that resource to be consistent with the semantics defined by
> the specification?
>
> For example suppose I follow a link from a test case to the
> requirement that it "validates". When I get that requirement
> resource and note that it includes a rdf:type property of http://
> open-services.net/ns/rm#Requirement. Can I assume that its other
> properties have the semantics as defined by the OSLC RM
> specification? If I can't I am not sure what I can do with the
> resource other than recognize that it exists.
>
> Arthur was saying that the current verbiage in the specification
> does not make any assumption, and proposed that it might be useful if it
did.
>
> The corollay might be that if that resource that I get from the
> "validates" link does not have a rdf:type property with
> oslc_rm:Requirement that I should not as a client assume that it is
> in fact a requirement, and instead deal with it gracefully.
>
> <jim/>
>
> jim conallen
> CAM Lead Architect
> jconallen at us.ibm.com
> Rational Software, IBM Software Group
>
>
> From: Martin Nally/Raleigh/IBM at IBMUS
> To: Arthur Ryman <ryman at ca.ibm.com>
> Cc: oslc-core at open-services.net, oslc-core-bounces at open-services.net
> Date: 12/16/2010 12:37 PM
> Subject: Re: [oslc-core] Oslc-Core Digest, Vol 11, Issue 24
> Sent by: oslc-core-bounces at open-services.net
>
> Thanks, Arthur - I wasn't aware of the versioning section of the spec.
>
> I completely agree with your comment about unexpected responses. I think
we
> need to keep reminding ourselves of this. I'm sensitive to this issue
> because I see a recurring pattern of people carrying over incorrect
> assumptions that they are used to making from previous systems they have
> worked on. For example, I spoke to a group that was very surprised to
learn
> that OSLC does not guarantee that if you follow a link from a resource
that
> conforms to one OSLC domain (for example the link from an OSLC test case
to
> the requirement that it validates) that you will necessarily land on a
> resource that conforms to some other compatible domain spec (for example
> the requirement spec). People who are steeped in a UML history are used
to
> making exactly this assumption, which is one of the reasons I wince when
I
> see UML diagrams connecting the OSLC domains. The problem with the UML
> assumption is that it creates a closed system, and all the domains
> reference each other transitively, so no single domain can be adopted
> without implicitly adopting all the others by transitive closure. This
> creates the sort of tight couplings that OSLC is trying to avoid.
>
> Best regards, Martin
>
> Martin Nally, IBM Fellow
> CTO and VP, IBM Rational
> tel: +1 (714)472-2690
>
>
>
> |------------>
> | From: |
> |------------>
>
>
>--------------------------------------------------------------------------------------------------------------------------------------------------|
> |Arthur Ryman/Toronto/IBM at IBMCA
|
>
>
>--------------------------------------------------------------------------------------------------------------------------------------------------|
> |------------>
> | To: |
> |------------>
>
>
>--------------------------------------------------------------------------------------------------------------------------------------------------|
> |Martin Nally/Raleigh/IBM at IBMUS
|
>
>
>--------------------------------------------------------------------------------------------------------------------------------------------------|
> |------------>
> | Cc: |
> |------------>
>
>
>--------------------------------------------------------------------------------------------------------------------------------------------------|
> |oslc-core at open-services.net, oslc-core-bounces at open-services.net
|
>
>
>--------------------------------------------------------------------------------------------------------------------------------------------------|
> |------------>
> | Date: |
> |------------>
>
>
>--------------------------------------------------------------------------------------------------------------------------------------------------|
> |12/15/2010 03:45 PM
|
>
>
>--------------------------------------------------------------------------------------------------------------------------------------------------|
> |------------>
> | Subject: |
> |------------>
>
>
>--------------------------------------------------------------------------------------------------------------------------------------------------|
> |Re: [oslc-core] Oslc-Core Digest, Vol 11, Issue 24
|
>
>
>--------------------------------------------------------------------------------------------------------------------------------------------------|
>
>
>
>
> Martin,
>
> I agree that clients should be able to gracefully handle unexpected
> responses.
>
> Do you disagree with the statement in general, or just when the
> complications of versioning are considered, i.e. "If a service claims to
> comply with a domain spec then resources returned by that service must
> comply with the domain spec"
>
> The OSLC Core does have a mechanism for requesting or specifying the
> version via the OSLC-Core-Version HTTP header. [1] The mechanism allows
the
> service to return a version of a resource that the client can handle. It
is
> therefore meaningful to talk about the version of the service, but this
may
> include support for back-levels of the service too. Even though resources
> may have been created by different versions of the service, the service
has
> a mechanism for returning a version of a resource that is compatible with
> the client. I assume that domain specs could define version headers
> specific to them.
>
> [1]
> http://open-services.net/bin/view/Main/OslcCoreSpecification?
> sortcol=table;up=#Specification_Versioning
>
> Regards,
>
___________________________________________________________________________
>
> Arthur Ryman, PhD, DE (Embedded imagemoved
to
> file:
pic42312.gif)
>
> Chief Architect, Project and Portfolio Management
>
> IBM Software, Rational
>
> Markham, ON, Canada | Office: 905-413-3077, Cell:
> 416-939-5063
>
>
>
>
>
>
> |------------>
> | From: |
> |------------>
>
>
>--------------------------------------------------------------------------------------------------------------------------------------------------|
> |Martin Nally/Raleigh/IBM at IBMUS
|
>
>
>--------------------------------------------------------------------------------------------------------------------------------------------------|
> |------------>
> | To: |
> |------------>
>
>
>--------------------------------------------------------------------------------------------------------------------------------------------------|
> |Arthur Ryman <ryman at ca.ibm.com>
|
>
>
>--------------------------------------------------------------------------------------------------------------------------------------------------|
> |------------>
> | Cc: |
> |------------>
>
>
>--------------------------------------------------------------------------------------------------------------------------------------------------|
> |oslc-core at open-services.net, oslc-core-bounces at open-services.net
|
>
>
>--------------------------------------------------------------------------------------------------------------------------------------------------|
> |------------>
> | Date: |
> |------------>
>
>
>--------------------------------------------------------------------------------------------------------------------------------------------------|
> |12/14/2010 07:08 PM
|
>
>
>--------------------------------------------------------------------------------------------------------------------------------------------------|
> |------------>
> | Subject: |
> |------------>
>
>
>--------------------------------------------------------------------------------------------------------------------------------------------------|
> |Re: [oslc-core] Oslc-Core Digest, Vol 11, Issue 24
|
>
>
>--------------------------------------------------------------------------------------------------------------------------------------------------|
>
>
>
>
> I think this confirms that the only safe option for a client is to assume
> nothing. I think the spec should say this. I don't think it's even safe
to
> assume that "the resources that you get from a service that claims to
> comply with a domain spec must comply with that domain spec". Let's
assume
> I'm a client that is programmed to understand version n of the XYZ OSLC
> specification. If I access an XYZ service, I might find resources created
> from version 1 through version n+m of the domain spec stored within the
> same service, so it probably isn't even meaningful to talk about the
> version of the service, unless it means simply the version of its
> service/service provider document. Since I can't know in advance what
> changes were introduced in versions n+1 through n+m, I can't really say
> what it means for the resources to be compliant with a spec, so I'd
better
> be prepared for the unexpected.
>
> Best regards, Martin
>
> Martin Nally, IBM Fellow
> CTO and VP, IBM Rational
> tel: +1 (714)472-2690
>
>
>
>
> |------------>
> | From: |
> |------------>
>
>
>--------------------------------------------------------------------------------------------------------------------------------------------------|
> |Arthur Ryman <ryman at ca.ibm.com>
|
>
>
>--------------------------------------------------------------------------------------------------------------------------------------------------|
> |------------>
> | To: |
> |------------>
>
>
>--------------------------------------------------------------------------------------------------------------------------------------------------|
> |Martin Nally/Raleigh/IBM at IBMUS
|
>
>
>--------------------------------------------------------------------------------------------------------------------------------------------------|
> |------------>
> | Cc: |
> |------------>
>
>
>--------------------------------------------------------------------------------------------------------------------------------------------------|
> |oslc-core at open-services.net, oslc-core-bounces at open-services.net
|
>
>
>--------------------------------------------------------------------------------------------------------------------------------------------------|
> |------------>
> | Date: |
> |------------>
>
>
>--------------------------------------------------------------------------------------------------------------------------------------------------|
> |12/14/2010 06:50 PM
|
>
>
>--------------------------------------------------------------------------------------------------------------------------------------------------|
> |------------>
> | Subject: |
> |------------>
>
>
>--------------------------------------------------------------------------------------------------------------------------------------------------|
> |Re: [oslc-core] Oslc-Core Digest, Vol 11, Issue 24
|
>
>
>--------------------------------------------------------------------------------------------------------------------------------------------------|
>
>
>
>
>
> Martin,
>
> When Jim raised this topic initially, I pointed out that OSLC does not
> currently make any statement about how type URIs should be used outside
> their domain specs, i.e. you should assume that the resource satisfies
the
> domain spec. All you can count on is the service, i.e. the resources that
> you get from a service that claims to comply with a domain spec must
> comply with that domain spec. However, it does seem natural that the type
> URIs (and any other property URIs) defined by one domain might be useful
> to other domains or other non-OSLC services. Since these type URIs are in
> the OSLC namespace, it seems appropriate that OSLC should specify their
> intended use, with the usual understanding that no organization can
> restrict how other organizations use URIs.
>
> No, I didn't consider versioning. I assume the versioning rules are
> specified by each domain and so any user of the type URIs should comply
> with that. Yes, this could be a can of worms when a resource has more
than
> one type URI since you'd have to specify the versions for each of the
> domains. This is a great topic for the "Mutli-Type" workgroup to discuss.
>
> Regards,
>
___________________________________________________________________________
>
>
> Arthur Ryman, PhD, DE
>
> Chief Architect, Project and Portfolio Management
> IBM Software, Rational
> Markham, ON, Canada | Office: 905-413-3077, Cell: 416-939-5063
>
>
>
>
>
> From:
> Martin Nally <nally at us.ibm.com>
> To:
> oslc-core at open-services.net
> Cc:
> oslc-core at open-services.net, oslc-core-bounces at open-services.net
> Date:
> 12/10/2010 11:30 AM
> Subject:
> Re: [oslc-core] Oslc-Core Digest, Vol 11, Issue 24
> Sent by:
> oslc-core-bounces at open-services.net
>
>
>
> >> the RDF representation of T SHOULD satisfy the OSLC Domain
> specification
> that defines T.
>
> Have you thought about what this means for versioning? Does this mean the
> 2.0 version of the OSLC specification? All past and future versions? I
> think this will open a can of worms. I think we should make the opposite
> statement - that when something says it is of some OSLC type, this
carries
> no guarantees whatever. Caveat emptor.
>
> Best regards, Martin
>
> Martin Nally, IBM Fellow
> CTO and VP, IBM Rational
> tel: +1 (714)472-2690
>
>
>
>
> From: oslc-core-request at open-services.net
>
> To: oslc-core at open-services.net
>
> Date: 12/09/2010 12:00 PM
>
> Subject: Oslc-Core Digest, Vol 11, Issue 24
>
> Sent by: oslc-core-bounces at open-services.net
>
>
>
>
>
>
> Send Oslc-Core mailing list submissions to
> oslc-core at open-services.net
>
> To subscribe or unsubscribe via the World Wide Web, visit
>
> http://open-services.net/mailman/listinfo/oslc-core_open-services.net
> or, via email, send a message with subject or body 'help' to
> oslc-core-request at open-services.net
>
> You can reach the person managing the list at
> oslc-core-owner at open-services.net
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Oslc-Core digest..."
>
>
> Today's Topics:
>
> 1. Re: Resources that have Multiple rdf:type Values (Arthur Ryman)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Wed, 8 Dec 2010 17:25:40 -0500
> From: Arthur Ryman <ryman at ca.ibm.com>
> To: Dave <snoopdave at gmail.com>
> Cc: oslc-core at open-services.net
> Subject: Re: [oslc-core] Resources that have Multiple rdf:type Values
> Message-ID:
>
> <OFBE176E2F.3D444635-ON852577F3.007A354B-852577F3.007B3507 at ca.ibm.com>
> Content-Type: text/plain; charset="US-ASCII"
>
> Dave,
>
> I was pointing out the status quo. However, our desire is that types be
> used in a predictable way.
>
> I am recommending that we add an explicit statement to our spec to avoid
> "capricious" use of OSLC-defined types. We don't "enforce" this via an
> ontology so we need to provide explicit guidance in the Core spec.
>
> Regards,
>
___________________________________________________________________________
>
>
> Arthur Ryman, PhD, DE
>
> Chief Architect, Project and Portfolio Management
> IBM Software, Rational
> Markham, ON, Canada | Office: 905-413-3077, Cell: 416-939-5063
>
>
>
>
>
> From:
> Dave <snoopdave at gmail.com>
> To:
> Arthur Ryman/Toronto/IBM at IBMCA
> Cc:
> oslc-core at open-services.net
> Date:
> 12/08/2010 04:56 PM
> Subject:
> Re: [oslc-core] Resources that have Multiple rdf:type Values
>
>
>
> On Wed, Dec 8, 2010 at 12:22 PM, Arthur Ryman <ryman at ca.ibm.com> wrote:
> > At the Core telecon today, Jim raised this topic. We need to continue
> the
> > discussion. Here is a suggestion for how to handle this:
> >
> > Any RDF resource representation MAY contain zero or more triples that
> have
> > a given URI, S, as the subject, and rdf:type as the predicate, If
there
> > is a triple of the form (S, rdf:type, T) where T is a type URI defined
> by
> > some OSLC Domain specification, then the RDF representation of T SHOULD
> > satisfy the OSLC Domain specification that defines T.
>
> I thought you argued against this point today, saying that you can
> only make that sort of inference when you that a resource is provided
> by a service that implements an OSLC specification.
>
> - Dave
>
>
>
>
>
>
>
> ------------------------------
>
> _______________________________________________
> Oslc-Core mailing list
> Oslc-Core at open-services.net
> http://open-services.net/mailman/listinfo/oslc-core_open-services.net
>
>
> End of Oslc-Core Digest, Vol 11, Issue 24
> *****************************************
>
>
>
>
> _______________________________________________
> Oslc-Core mailing list
> Oslc-Core at open-services.net
> http://open-services.net/mailman/listinfo/oslc-core_open-services.net
>
>
>
>
>
>
> [attachment "pic42312.gif" deleted by James Conallen/Philadelphia/
> IBM] _______________________________________________
> Oslc-Core mailing list
> Oslc-Core at open-services.net
> http://open-services.net/mailman/listinfo/oslc-core_open-services.net
More information about the Oslc-Core
mailing list