[oslc-core] Better name for OSLC indexing profile
Benjamin Williams
bwilliams at uk.ibm.com
Mon Apr 4 06:07:00 EDT 2011
Hi Frank, all
After the WG call on Wednesday I started to think about the implications
of the 'Published Resources' term that I proposed.
I want to understand the relationship between 'publishing resources' to be
made available via the change log, and 'publishing resources' as a general
OSLC API construct.
Are these two things always describing the same capability, and therefore
the same set of resources?
I believe so. Whilst I don't believe that all indexers will always want to
index all available resources (often indexing a subset of resources might
be desired), I do believe that we shouldn't second-guess the use-cases,
and thus the set of published resources for the change log should indeed
be the exact same set of resources 'published' via the generic OSLC API.
(Note this doesn't imply that providers should not also be able to make
subsets of resources available via additional Query Capabilities)
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.
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)?
On the naming issue around the tracking/logging capability my thoughts
are:
- tracking implies a partial assumption of client use case
- logging describes the mechanism by which the information is delivered
- what's really important is the 'data' or 'information' and how that
changes over time (history)
- some naming proposals talk about 'change' but are not explicit about the
subject of the change (resources)
- some naming proposals talk about 'tracking resources' but are not
explicit about what is being tracked (changes)
- 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.
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'
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: 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/f5f8cf3f/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/f5f8cf3f/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/f5f8cf3f/attachment.gif>
More information about the Oslc-Core
mailing list