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: [email protected] 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 <[email protected]> To: Benjamin Williams/UK/IBM@IBMGB Cc: oslc-core <[email protected]>, [email protected] 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
