Re: [higgins-dev] getContextId change proposal

["Markus Sabadello" <msabadello@xxxxxxxxxxxxx>]

I've also been thinking about the relation between Context ID and Context UDI. We should wait for Paul or Drummond to give us their thoughts.

My (non-authoritative) thoughts are:

1) In my mind Context ID and Context UDI are the same. Both are Strings that resolve to an IContext. Therefore we don't need IContextId and ContextIdFactory anymore and should delete them.

We should change IContextFactory.createContext
from
public IContext createContext(IContextId contextID)
to
public IContext createContext(Map contextConfiguration)

And we should also change IContext.getContextId
from
public IContextId getContextId()
to
public String getContexId()

I know this sounds a bit radical and I'm probably missing some use case.

2) Most of the IContextId implementations I wrote override toString() and return the string that was used to instantiate the IContextId. When I wrote them I thought that was obvious, but it seems it's not, so yes, I agree there could be more "guidance" in the interface.

3) There's a "GenericContextId" you can return, which takes in its constructor the context types and context configuration. This is the only IContextId implementation that doesn't override toString() because it's not created from a String.

Markus

On Tue, Aug 19, 2008 at 10:14 PM, Jim Sermersheim <jimse@xxxxxxxxxx> wrote:

Ok, a few follow-up questions as I try to push this change in:

1) The old IContext.getContextID used to return a String which was said to match the value of the  http://www.eclipse.org/higgins/ontologies/2008/6/higgins#contextId attribute on this context.  This is consistent with the data model as represented at http://wiki.eclipse.org/ContextId. So the question in my mind is:  Do all Contexts have a UDI which identifies them?  If so, what does IContextID offer above that, and further -- how does one use IContextID to get at the UDI which was used to produce a given Context?

2) This thread proposes to use toString() to get at some representation of the URI or URIs which were used to create the IContextID.  IContextID doesn't override this method and create a new contract or offer guidance as to what is expected from toString().  Should it be?

3) The jena2 cp has ways of creating contexts which don't require an IContextID.  What's the proper way to fabricate an IContextID (for purposes of returning from IContext.getContextID() in this case?

Jim

>>> "Tom Doman" <tdoman@xxxxxxxxxx> 08/14/08 1:41 PM >>>

Yeah, okay, that would probably be sufficient.  I'll use that.

Tom

>>> "Markus Sabadello" <msabadello@xxxxxxxxxxxxx> 08/14/08 12:11 PM >>>
The types and URIs have nothing to do with each other. You could even have a
ContextId without any URI at all, however you would always have at least one
type.

The IContextId implementations I made all override the toString() method in
which they return the original string from which the ContextId was
generated. Is that what you're talking about?

Markus

On Thu, Aug 14, 2008 at 8:04 PM, Tom Doman <tdoman@xxxxxxxxxx> wrote:

> Yeah, but if the types and URIs correlate, I'd like to have a toString()
> that puts
> them together in some nice way.  Oh, also for auditing too.
>
> Tom
>
> >>> "Markus Sabadello" <markus.sabadello@xxxxxxxxx> 08/14/08 11:56 AM >>>
> Hmm.. The types are strings anyway, and the URIs can just be toString()ed,
> no?
>
> Markus
>
> On Thu, Aug 14, 2008 at 7:33 PM, Tom Doman <tdoman@xxxxxxxxxx> wrote:
>
> > It would also be nice to have IContextId have some helpers that turn the
> > context URIs and context Types into Strings that can be displayed and\or
> > logged.
> >
> > >>> "Tom Doman" <tdoman@xxxxxxxxxx> 08/14/08 11:22 AM >>>
> > Currently, getContextId() returns a single URI.  The IContextId interface
> > may return a set of URIs comprising the complete context ID.  I'd like to
> > proposed that getContextId() be changed to return either a URI [ ] or and
> > IContextId so we can get at the full picture that this API should allow.
> >
> > Tom
> >
> >
> > _______________________________________________
> > higgins-   dev mailing list
> > higgins-   dev@xxxxxxxxxxx
> > https://dev.eclipse.org/mailman/listinfo/higgins-   dev
> >
> >
> > _______________________________________________
> > higgins-  dev mailing list
> > higgins-  dev@xxxxxxxxxxx
> > https://dev.eclipse.org/mailman/listinfo/higgins-  dev
> >
>
>
> _______________________________________________
> higgins- dev mailing list
> higgins- dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/higgins- dev
>

_______________________________________________
higgins-dev mailing list
higgins-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/higgins-dev

_______________________________________________
higgins-dev mailing list
higgins-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/higgins-dev