Steve,
The recommended Web architecture for identifiers is to use URIs. That way
it is possible for third-parties to add information about them, i.e. the
identifier can become the subject of additional triples. You can't do that
with literals. Furthermore, you can request a URI and get back some useful
information. I hope OSLC can do this for all URIs in our domain.
There are some other reasons, e.g. design consistency, uniform spelling
(case is significant).
I sympathize with the impl comments, but the spec is still open for
correction. This seems like a minor change.
Regards,
___________________________________________________________________________
Arthur Ryman, PhD, DE
Chief Architect, Project and Portfolio Management
IBM Software, Rational
Markham, ON, Canada | Office: 905-413-3077, Cell: Twitter | Facebook |
416-939-5063 YouTube
|------------>
| From: |
|------------>
>--------------------------------------------------------------------------------------------------------------------------------------------------|
|Steve K Speicher/Raleigh/IBM@IBMUS
|
>--------------------------------------------------------------------------------------------------------------------------------------------------|
|------------>
| To: |
|------------>
>--------------------------------------------------------------------------------------------------------------------------------------------------|
|Arthur Ryman <[email protected]>
|
>--------------------------------------------------------------------------------------------------------------------------------------------------|
|------------>
| Cc: |
|------------>
>--------------------------------------------------------------------------------------------------------------------------------------------------|
|[email protected]
|
>--------------------------------------------------------------------------------------------------------------------------------------------------|
|------------>
| Date: |
|------------>
>--------------------------------------------------------------------------------------------------------------------------------------------------|
|07/27/2010 03:10 PM
|
>--------------------------------------------------------------------------------------------------------------------------------------------------|
|------------>
| Subject: |
|------------>
>--------------------------------------------------------------------------------------------------------------------------------------------------|
|Re: [oslc-core] oslc:usage should be a Resource
|
>--------------------------------------------------------------------------------------------------------------------------------------------------|
The value that the core defines for default happens to use a anyURI value
type. Since it has been defined as String, implementations have done it
this way already. So it would possible for a domain to define "testCase"
but they haven't (or at least I don't think they have).
Does it provide any value for this usage string to be a URI for RDF? Does
it make build a more meaningful graph?
I can see some merit in the change but I don't see a bit RDF advantage for
the switch.
I only hesitate as we have aligned some impls, spec and samples already.
Yet another change could be contained, just making sure its worth it at
this stage.
Thanks,
Steve Speicher | IBM Rational Software | (919) 254-0645
> From: Arthur Ryman <[email protected]>
> To: [email protected]
> Date: 07/27/2010 02:40 PM
> Subject: [oslc-core] oslc:usage should be a Resource
> Sent by: [email protected]
>
> oslc:usage is defined as a String. However, the spec says its an
> identifier and gives the example value of
> http://open-services/ns/core#default
>
> In RDF, identifiers should normally be URIs. Therefore oslc:usage should
> be a Resource.
>
> 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
> Twitter | Facebook | YouTube
