[oslc-core] Better name for OSLC indexing profile

Frank Budinsky frankb at ca.ibm.com
Thu Mar 31 16:27:42 EDT 2011


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:

   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.
   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).
   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:

   Active Content Publishing
   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.


                                                                                                                           
  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



                                                                                                                           
  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


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://open-services.net/pipermail/oslc-core_open-services.net/attachments/20110331/465e05ed/attachment-0003.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: graycol.gif
Type: image/gif
Size: 105 bytes
Desc: not available
URL: <http://open-services.net/pipermail/oslc-core_open-services.net/attachments/20110331/465e05ed/attachment.gif>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ecblank.gif
Type: image/gif
Size: 45 bytes
Desc: not available
URL: <http://open-services.net/pipermail/oslc-core_open-services.net/attachments/20110331/465e05ed/attachment-0001.gif>


More information about the Oslc-Core mailing list