[oslc-core] Oslc-Core Digest, Vol 11, Issue 24
Martin Nally
nally at us.ibm.com
Thu Dec 16 12:34:52 EST 2010
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 image moved 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pic42312.gif
Type: image/gif
Size: 360 bytes
Desc: not available
URL: <http://open-services.net/pipermail/oslc-core_open-services.net/attachments/20101216/ad63d6d6/attachment.gif>
More information about the Oslc-Core
mailing list