[oslc-core] Better name for OSLC indexing profile
Frank Budinsky
frankb at ca.ibm.com
Mon Apr 4 10:24:26 EDT 2011
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:
"Resource Changelog Capability"
"Resource Changes Capability"
"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.
>
>
> 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: [image removed]
>
> [image removed]
>
>
>
>
> 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: Frank Budinsky <frankb at ca.ibm.com>
> Cc: oslc-core <oslc-core at open-services.net>, oslc-core-
> bounces at open-services.net
> Date: 01-04-2011 21:56
> Subject: Re: [oslc-core] Better name for OSLC indexing profile
> Sent by: oslc-core-bounces at open-services.net
>
>
>
> Thanks to everyone that provided feedback on this issue. I now think
> I have a better way to describe this.
>
> As mentioned below, to implement an "indexer" we will need 3 new
> capabilities of a service provider:
> 1. Expose its complete set of "public resources". By public, we mean
> all the resources that the service provider does not consider to be
> internal implementation artifacts (not to be confused with anything
> to do with access permission's). At the previous WG call, the word
> "published resources" was suggested as a good way to describe these
> resources.
> 2. Provide a change log that lists change events for the set of
> published resources in (1), as well as creation events for new
> resources that would have been included in (1).
> 3. Provide access to security information (ACLs) for the published
> resources, to allow a client to mirror the access rules of the
> underlying tools.
> If we were to name the capabilities, themselves, based on our
> discussions I would name them something like this:
> 1. Resource Publishing
> 2. Resource Tracking (or Logging)
> 3. Resource Security
>
> All three capabilities are intended to be optional OSLC features,
> but #2 does prereq #1. That is, you can't provide logging/tracking
> support without also publishing the resources being tracked. In that
> sense, you can easily think about #2 as being a profile, instead of
> a capability. Add to that the fact that #3 isn't part of the
> ChangeLog proposal (it's an independent capability, and
> intentionally being left as a separate OSLC proposal), some of the
> profile name suggestions were, not surprisingly, the same as these
> #1 or #2 capability names.
>
> What I have been trying to do is find an appropriate name for the
> combination of #1, #2, and #3, which would then be used to talk
> about the overall functionality and even come up with a NS that
> could be used for resources of all 3 capabilities. I'm now thinking
> that isn't really a good idea anyway, since there really are two
> completely independent proposals in this picture (ChangeLog and
Security).
>
> Given that, I think we should simply use the term "Indexing
> Requirements" to refer to the three capabilities that are needed for
> an indexer, and use the logging/tracking capability (#2) to refer to
> the ChangeLog functionality. That is, we use the name:
>
> "Resource Tracking Capability" --- is "Resource Logging Capability"
> or "Change Logging Capability" a better/clearer name?
>
> which also prereqs the:
>
> "Resource Publishing Capability"
>
> Unless someone can see a problem with this, I'll update the
> ChangeLog proposal using this terminology. Since the next version is
> intended to be the official "convergence" draft, it would be nice to
> have agreement on this, but I suppose we're still allowed to change
> things like this before finalization if we want to.
>
> Thanks,
> Frank
>
> Frank Budinsky---03/31/2011 04:27:50 PM---Hi all, I'd like to finish
> this discussion soon, if we can. The discussion so far
>
>
> From:
>
>
> Frank Budinsky/Toronto/IBM at IBMCA
>
>
> To:
>
>
> Jim des Rivieres/Ottawa/IBM at IBMCA
>
>
> Cc:
>
>
> oslc-core <oslc-core at open-services.net>
>
>
> Date:
>
>
> 03/31/2011 04:27 PM
>
>
> Subject:
>
>
> Re: [oslc-core] Better name for OSLC indexing profile
>
>
> Sent by:
>
>
> oslc-core-bounces at open-services.net
>
>
>
>
>
> Hi all,
>
> I'd like to finish this discussion soon, if we can. The discussion
> so far has helped us articulate exactly what this "profile" is, even
> if we haven't been able to come up with a good name yet. Let me try
> to summarize and then offer a couple of new name suggestions.
>
> This profile requires a service provider to implement the following
> three capabilities:
> 1. Expose its complete set of "public resources". By public, we mean
> all the resources that the service provider does not consider to be
> internal implementation artifacts (not to be confused with anything
> to do with access permission's). At the previous WG call, the word
> "published resources" was suggested as a good way to describe these
> resources.
> 2. Provide a change log that lists change events for the set of
> published resources in (1), as well as creation events for new
> resources that would have been included in (1).
> 3. Provide access to security information (ACLs) for the published
> resources, to allow a client to mirror the access rules of the
> underlying tools.
>
> In a more concise form, we can describe this as:
> A service provider must publish its contents (resources), including
> change information (because the content is dynamic) and access
> control information.
>
> Jim used the word "Active", below, to capture the dynamic aspect.
> Sticking with that, I would suggest the following name for the profile:
> 1. Active Content Publishing
> 2. Content Publishing
>
> Personally, I like #2, "Content Publishing Profile". I think it's
> short enough and I don't think "Active" is not needed because it's
> obvious that a service provider's contents is changing/active. A
> service provider should just be asked to "publish its contents",
> which means enumerate the resources, including change information to
> allow clients to keep up to date with the changing publication.
>
> Please send me your votes or a better suggestion if you can think of one.
>
> Thanks,
> Frank.
>
> Jim des Rivieres---03/24/2011 01:51:07 PM---I don't have as much a
> problem as some with using the driving use case in the name. I believe in
ca
>
>
> From:
>
>
> Jim des Rivieres/Ottawa/IBM
>
>
> To:
>
>
> Frank Budinsky/Toronto/IBM at IBMCA
>
>
> Cc:
>
>
> oslc-core <oslc-core at open-services.net>
>
>
> Date:
>
>
> 03/24/2011 01:51 PM
>
>
> Subject:
>
>
> Re: [oslc-core] Better name for OSLC indexing profile
>
>
>
>
> I don't have as much a problem as some with using the driving use
> case in the name. I believe in calling a spade a bloody shovel
> [OED], even if shovels can be used for other things.
>
> If I step way, way, back and imagine that the particular protocol we
> are specifying here catches like wildfire in the open web (think
> Atom or OAuth), the question I ask is what name would we like it to
> be known by. Something that the world can latch onto, and have a
> chance of keeping it straight in their minds amid myriad other
> Internal protocols.
>
> I believe the main reason that apps will be signing up to be
> providers is that they are sitting on some data resources that they
> would like to expose in an RDF format so that other apps would be
> able to build queryable indexes from. Any old app can expose
> resources with RDF representations without supporting this new
> protocol. So the RDF by itself is not sufficient. And this protocol
> says nothing about the indexes that may get built. Crucially, this
> protocol is about exposing information in RDF form in a way that
> support someone else to build and maintain an RDF-based index. And
> its not that interesting if the data is static - you'd have no need
> of a change log. So being a dynamic source also seems important (#1-
> #5 all touch on this aspect.
>
> So how about the "Active RDF Index Source" protocol. And that when
> we talk about a OSLC domain service provider, we could talk about
> what it would mean for them to support the "Active RDF Index Source
> Profile", which would entail implementing the provider role of the
> Active RDF Index Source protocol, and providing specified enties in
> OSLC service, service provider, and service provider catalogs that
> make its Active RDF Index Sources discoverable.
>
> Regards,
> Jim
>
> [OED] See entry in http://en.wikipedia.org/wiki/To_call_a_spade_a_spade
>
>
> Frank Budinsky---03/24/2011 11:34:47 AM---As discussed in the
> meeting yesterday, I've been using the term "Indexing Profile" (see
> http://open-
>
>
> From:
>
>
> Frank Budinsky/Toronto/IBM at IBMCA
>
>
> To:
>
>
> oslc-core <oslc-core at open-services.net>
>
>
> Date:
>
>
> 03/24/2011 11:34 AM
>
>
> Subject:
>
>
> [oslc-core] Better name for OSLC indexing profile
>
>
> Sent by:
>
>
> oslc-core-bounces at open-services.net
>
>
>
>
>
> As discussed in the meeting yesterday, I've been using the term
> "Indexing Profile" (see http://open-services.net/bin/view/Main/
> IndexingProposals for details) to describe the capabilities that
> MUST be provided by a service provider to support indexing (e.g., an
> enumeration of resources, a Change Log, etc). It was pointed out
> that, although indexing is the primary motivating use case, the
> profile we're talking about is really more general and should
> therefore have a more general name.
>
> What this profile really provides is the capabilities required by a
> client that wants to see content and track changes to content of a
> service provider. Some suggested names for this profile are:
> 1. Observer Profile
> 2. Notification Profile
> 3. Change Log Profile
> 4. Content Tracking Profile
> 5. Service Tracking Profile
>
> The first 3 seem not to cover the "enumeration of resources" part of
> the profile (and other things like security, which will also be part
> of the profile), so my vote so far would be for #4 or #5.
>
> Please let me know which of these name you prefer or if you have a
> better suggestion.
>
> Thanks,
> Frank.
>
>
> oslc-core-bounces at open-services.net wrote on 03/23/2011 11:39:32 AM:
>
> > [image removed]
> >
> > [oslc-core] Continuing Change Log and Baselines discussions
> >
> > Dave
> >
> > to:
> >
> > oslc-core
> >
> > 03/23/2011 11:41 AM
> >
> > Sent by:
> >
> > oslc-core-bounces at open-services.net
> >
> > We had a good discussion of Change Log issues today, thanks to Frank
> > for leading, but we did not finish. You can find my notes from the
> > meeting on the agenda page here:
> >
> > http://open-services.net/bin/view/Main/OslcCoreMeeting20110323
> >
> > Since we did not finish the discussion, I'd like to schedule a
> > follow-up meeting next week:
> >
> > OSLC Core WG Meeting: Change Log follow-up Meeting
> > March 30, 2011 - 10AM US/ET
> >
> > I would also like to propose that we meet the week after that to
> > follow up on the Baselines discussion:
> >
> > OSLC Core WG Meeting: Baselines follow-up Meeting
> > April 6, 2011 - 10AM US/ET
> >
> > Nick: does April 6 work for you?
> >
> > Thanks,
> > Dave
> >
> > _______________________________________________
> > Oslc-Core mailing list
> > Oslc-Core at open-services.net
> > http://open-services.net/mailman/listinfo/oslc-core_open-services.net
> _______________________________________________
> Oslc-Core mailing list
> Oslc-Core at open-services.net
> http://open-services.net/mailman/listinfo/oslc-core_open-services.net
>
>
> _______________________________________________
> Oslc-Core mailing list
> Oslc-Core at open-services.net
> http://open-services.net/mailman/listinfo/oslc-core_open-services.net
>
> [attachment "graycol.gif" deleted by Benjamin Williams/UK/IBM]
> [attachment "ecblank.gif" deleted by Benjamin Williams/UK/IBM]
> _______________________________________________
> Oslc-Core mailing list
> Oslc-Core at open-services.net
> http://open-services.net/mailman/listinfo/oslc-core_open-services.net
>
>
>
>
>
> 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/91a14150/attachment-0003.html>
More information about the Oslc-Core
mailing list