In knowledge representations like RDF, as opposed to programming languages,
there is a difference between a multi-valued property and a list. For a
multi-valued property, there is no concept of order - the values form a
set, not a list - and the set is also not closed - there may be other
values for the same property kicking around in other resources. What this
means is that the parameters of an operation are not an example of a
multi-valued property - this example would probably be modelled in RDF as a
collection (both closed and ordered). RDF has constructs for this. The
collection can be a separate resource, or can be in the same resource as
the operation. The RDF primer has quite a bit of info on this:
http://www.w3.org/TR/rdf-primer/#containers and
http://www.w3.org/TR/rdf-primer/#collections (you may know all this
already). I agree with you that GETing a full LIST and then PUTing it back
is clumsy as a mechanism for updating containers and collections - it would
be interesting to see what better options people can imagine.
Best regards, Martin
Martin Nally, IBM Fellow
CTO and VP, IBM Rational
tel: (949)544-4691
|------------>
| From: |
|------------>
>--------------------------------------------------------------------------------------------------------------------------------------------------|
|James Conallen/Philadelphia/IBM
|
>--------------------------------------------------------------------------------------------------------------------------------------------------|
|------------>
| To: |
|------------>
>--------------------------------------------------------------------------------------------------------------------------------------------------|
|Martin Nally/Raleigh/IBM@IBMUS
|
>--------------------------------------------------------------------------------------------------------------------------------------------------|
|------------>
| Cc: |
|------------>
>--------------------------------------------------------------------------------------------------------------------------------------------------|
|[email protected], [email protected],
[email protected], Paul McMahan/Raleigh/IBM@IBMUS, Arthur Ryman
|
|<[email protected]>
|
>--------------------------------------------------------------------------------------------------------------------------------------------------|
|------------>
| Date: |
|------------>
>--------------------------------------------------------------------------------------------------------------------------------------------------|
|12/09/2009 05:39 PM
|
>--------------------------------------------------------------------------------------------------------------------------------------------------|
|------------>
| Subject: |
|------------>
>--------------------------------------------------------------------------------------------------------------------------------------------------|
|Re: [OSLC] OSLC QM 1.0 specification
|
>--------------------------------------------------------------------------------------------------------------------------------------------------|
When managing multi-valued properties in this way, is ordering implied by
order in the document? For example in UML Models of operations, the order
of parameters of an operation is important.
Inserting new values in a specific position would naturally require the
entire document to be PUT back, with the new property inserted in the
correct place. Or perhaps some other more elaborate mechanism could be
invented to allow the insertion or deletion of specific values.
<jim/>
jim conallen
[email protected]
Rational Software, IBM Software Group
|------------>
| From: |
|------------>
>--------------------------------------------------------------------------------------------------------------------------------------------------|
|Martin Nally/Raleigh/IBM@IBMUS
|
>--------------------------------------------------------------------------------------------------------------------------------------------------|
|------------>
| To: |
|------------>
>--------------------------------------------------------------------------------------------------------------------------------------------------|
|Paul McMahan/Raleigh/IBM@IBMUS, Arthur Ryman <[email protected]>
|
>--------------------------------------------------------------------------------------------------------------------------------------------------|
|------------>
| Cc: |
|------------>
>--------------------------------------------------------------------------------------------------------------------------------------------------|
|[email protected], [email protected],
[email protected]
|
>--------------------------------------------------------------------------------------------------------------------------------------------------|
|------------>
| Date: |
|------------>
>--------------------------------------------------------------------------------------------------------------------------------------------------|
|12/09/2009 03:08 PM
|
>--------------------------------------------------------------------------------------------------------------------------------------------------|
|------------>
| Subject: |
|------------>
>--------------------------------------------------------------------------------------------------------------------------------------------------|
|Re: [OSLC] OSLC QM 1.0 specification
|
>--------------------------------------------------------------------------------------------------------------------------------------------------|
|------------>
| Sent by: |
|------------>
>--------------------------------------------------------------------------------------------------------------------------------------------------|
|[email protected]
|
>--------------------------------------------------------------------------------------------------------------------------------------------------|
This design adopts the design for multi-valued properties documented in the
CM spec. I don't think this is a good design and we shouldn't propagate it.
The OSLC estimation workgroup is doing this the "right" way, as shown in
this example:
<?xml version="1.0"?>
<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#";
xmlns:dc="http://purl.org/dc/elements/1.1/";
xmlns:ems="http://open-services.net/software-metrics/";>
<ems:Project
rdf:about="http://braintwistors.example.com/ems/v1.0/Project/4201";>
<dc:title>Tsunami 1.0</dc:title>
<dc:description>
The goal of ...
</dc:description>
...
<ems:hasEstimate
rdf:resource="
http://braintwistors.example.com/ems/v1.0/Estmate/4203"; />
<ems:hasEstimate
rdf:resource="
http://braintwistors.example.com/ems/v1.0/Estmate/4204"; />
...
<!-- other properties of this project resource have been omitted for
brevity -->
</ems:Project>
</rdf:RDF>
In other words, a multi-valued property is just what it says - a property
with multiple values, as illustrated here by ":ems:hasEstimate". You do not
introduce a separate collection resource with separate link resources -
that design is not in the spirit of REST, it's just an old-fashioned OO
programming API exposed via http.
Best regards, Martin
Martin Nally, IBM Fellow
CTO and VP, IBM Rational
tel: (949)544-4691
Inactive hide details for Paul McMahan---12/09/2009 12:05:55 PM---The OSLC
Quality Management V1 specification is available at Paul
McMahan---12/09/2009 12:05:55 PM---The OSLC Quality Management V1
specification is available at : http://open-services.net/bin/view/Mai
From: Paul McMahan/Raleigh/IBM@IBMUS
To: [email protected]
Cc: [email protected]
Date: 12/09/2009 12:05 PM
Subject:: [OSLC] OSLC QM 1.0 specification
Sent by: [email protected]
The OSLC Quality Management V1 specification is available at :
http://open-services.net/bin/view/Main/QmSpecificationV1
I would like to thank the Quality Management workgroup members (BigLever,
IBM, Sogeti, and Tieto) for their participation in the workgroup and
contributions to the specification. The broader OSLC community is invited
to view the specification and provide any feedback in the wiki or via the
[email protected] mailing list. The Quality Management V2
specification effort is expected to get underway soon so any feedback on
the V1 specification will be especially valuable.
Best wishes.
Paul McMahan
Rational Quality Management
[email protected]
_______________________________________________
Community mailing list
[email protected]
http://open-services.net/mailman/listinfo/community_open-services.net.
_______________________________________________
Community mailing list
[email protected]
http://open-services.net/mailman/listinfo/community_open-services.net
