[oslc-core] Better name for OSLC indexing profile

Mon Apr 4 11:43:55 EDT 2011

Thanks for the reply Frank...

>>> In what spec is the term "published resources" defined?

I don't know that it is (yet), and I agree the term should be defined. 
I was questioning why we need a specific named capability, but you've 
addressed that question with the below comment.

>>>Yes, but since Query Capability is completely optional in the core 
spec, and furthermore, there is no way to know which of the (possibly 
many) Query Capabilities is exposing the "total set of resources", we need 
an optional capability to describe how that is to be done.
My proposal for this "Resource Publishing Capability" had been that a 
service provider MUST annotate 1 or more of it's associated Query 
Capabilities with a special oslc:usage value, something like"
http://open-services/ns/core/log#resources".

A question for my own understanding...if a service provider annotates more 
than 1 of its Query Capabilities via the oslc:usage parameter, then how 
does a consumer know which of the (possibly many) Query Capabilities is 
exposing the "total set of resources"?

>>> If, however, we all agree that this "published resources" concept 
should be a core OSLC capability then I would suggest a URI more like 
this:

oslc:usage = "http://open-services/ns/core#published"

I'm still not sure in which spec this capability would be described. 
Anybody?

Makes sense to me for it to be an optional core capability that is a 
mandatory capability of the indexing profile.
>>> This makes me think that any of the following names would be quite 
reasonable:
1.      "Resource Changelog Capability" 
2.      "Resource Changes Capability" 
3.      "Resource History Capability"

I could live with any of these names, but personally, I think I favour #1, 
since it has the word "log" in it, which is exactly what we're providing. 
Another reason for including the word "log" is, as Mike Loeffler pointed 
out on another thread, this design is very much like a "database 
transaction log".

Likewise any of the three above names work for me, as none make 
assumptions about a consumers use-case, though agree #1 is maybe 
preferable since it accurately describes the way in which the historical 
information is delivered.

Regards

Benjamin Williams
Rational Reporting Strategy Lead
Senior Product Manager, Rational Reporting
IBM Software, Rational

Phone: 44-118 9793107
E-mail: bwilliams at uk.ibm.com
Find me on:  

IBM United Kingdom Limited 
Registered in England and Wales with number 741598 
Registered office: PO Box 41, North Harbour, Portsmouth, Hants. PO6 3AU

From:   Frank Budinsky <frankb at ca.ibm.com>
To:     Benjamin Williams/UK/IBM at IBMGB
Cc:     oslc-core <oslc-core at open-services.net>, 
oslc-core-bounces at open-services.net
Date:   04-04-2011 15:25
Subject:        Re: [oslc-core] Better name for OSLC indexing profile

Hi Benjamin,

> In other words 'published resources' is a term with a single well 
> defined meaning (the total set of resources available via the 
> providers OSLC service) that has applicability beyond just the 
> ChangeLog proposal. 

+1, but I have a question. In what spec is the term "published resources" 
defined? I couldn't find it anywhere, and therefore thought it needs to be 
defined along with the indexing/changelog spec. I'd be much happier to 
simply refer to another spec.

> 
> What I don't understand therefore is why we actually need a specific
> term for a capability here? (Resource Publishing Capability) 
> Aren't we just saying that the provider needs to expose at least one
> Query Capability (oslc:queryBase)? 

Yes, but since Query Capability is completely optional in the core spec, 
and furthermore, there is no way to know which of the (possibly many) 
Query Capabilities is exposing the "total set of resources", we need an 
optional capability to describe how that is to be done. My proposal for 
this "Resource Publishing Capability" had been that a service provider 
MUST annotate 1 or more of it's associated Query Capabilities with a 
special oslc:usage value, something like"
http://open-services/ns/core/log#resources". If, however, we all agree 
that this "published resources" concept should be a core OSLC capability 
then I would suggest a URI more like this:

oslc:usage = "http://open-services/ns/core#published"

I'm still not sure in which spec this capability would be described. 
Anybody?

> - hence I would suggest something along the lines of 
> 
> 'Resource Change Information Capability' 
> 'Resource Change History Capability' 
> 
> If an abbreviated form is really necessary, then 'Resource History' 
> would seem to be to be most descriptive of what the capability provides. 

Looking at Wikipedia's definition of Changelog, I found this:
A changelog is a log or record of changes made to a project, such as a 
website or software project ... Although the canonical naming convention 
for the file is ChangeLog,[1] it is sometimes alternatively named as 
CHANGES or HISTORY ...
This makes me think that any of the following names would be quite 
reasonable:
1.      "Resource Changelog Capability" 
2.      "Resource Changes Capability" 
3.      "Resource History Capability"

I could live with any of these names, but personally, I think I favour #1, 
since it has the word "log" in it, which is exactly what we're providing. 
Another reason for including the word "log" is, as Mike Loeffler pointed 
out on another thread, this design is very much like a "database 
transaction log".

> Finally, regarding the collection of Core features required to 
> support an index, to remain consistent with usage elsewhere 
> (Reporting) I support 'Indexing Profile' as a preferred term to 
> 'Indexing Requirements' 

I'd be happy with that, if nobody objects.

Thanks,
Frank.

Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number 
741598. 
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://open-services.net/pipermail/oslc-core_open-services.net/attachments/20110404/37d62693/attachment-0003.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/jpeg
Size: 488 bytes
Desc: not available
URL: <http://open-services.net/pipermail/oslc-core_open-services.net/attachments/20110404/37d62693/attachment.jpe>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/gif
Size: 360 bytes
Desc: not available
URL: <http://open-services.net/pipermail/oslc-core_open-services.net/attachments/20110404/37d62693/attachment.gif>