Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [higgins-dev] Change to IDigitalSubject

Sounds good, Jim. I think the renaming to IComplexValue would remove the confusion.

Thanks
Raj


Inactive hide details for "Jim Sermersheim" <jimse@xxxxxxxxxx>"Jim Sermersheim" <jimse@xxxxxxxxxx>


          "Jim Sermersheim" <jimse@xxxxxxxxxx>
          Sent by: higgins-dev-bounces@xxxxxxxxxxx

          09/20/2006 03:29 PM

          Please respond to
          "Higgins (Trust Framework) Project developer discussions" <higgins-dev@xxxxxxxxxxx>

To

"Higgins (Trust Framework) Project developer discussions" <higgins-dev@xxxxxxxxxxx>

cc


Subject

Re: [higgins-dev] Change to IDigitalSubject

Until we got to the notion of attribute values, we were creating something fairly abstracted from RDF. It started getting surfaced with with attribute values, schema, and search filters.

I knew we needed a way to represent the notion of simple values, and talked myself into using ILiteral for that. I still have unresolved questions and am not sure I got it right. Next, I thought we needed a way to represent complex values. I assumed the right way to do that was with IResource, which included a type, name, and its own attributes.

Thinking more about it, I think I got IResource wrong. To be more symmetric with ILiteral, I don't think it needs a type (as type is given at the IAttribute level). I only decided to give it a name since in the RDF instance they have names, and I figured there may be some future use for that.

Likely what we should do is rename ILiteral to ISimpleValue, and rename IResource to IComplexValue (as to not tie ourselves to RDF), make IComplexValue simply a collection of attributes (as IResource was initially), and put everything else back as it was (IDigitalSubject could implement IComplexValue if we wanted -- but will add its own type and name)

What do you all think of this suggestion?

Jim

p.s. after looking at Jena, it seems like a good architecture, but something we would want to sit next to IdAS -- an alternate interface to the data.

>>> Greg Byrd <gbyrd@xxxxxxxx> 9/20/06 11:38 AM >>>
It's just a suggestion. I'll be happy to hear input from others.

If, however, IResource is meant to encapsulate a resource in the RDF
sense, then it makes sense to me that IDigitalSubject is a specific type
of resource. In other words, a DS will always be a resource in the RDF
sense. So if we're exposing the notion of RDF resource through the API,
then it's consistent to view IDigitalSubject that way.

Just to play Devil's advocate -- if we're exposing RDF notions in the
API, why not use Jena or some other API instead of inventing our own.
They already have Resource, Literal, etc. (The practical answer might
be that it takes too long to get permission from Eclipse to in clude
third-party code...)

...Greg


Jim Sermersheim wrote:
> We can do it that way. I was hesitant to do that because I didn't know
> where IResource might differ from IDigitalSubject in the future.
>
> I'll change it to follow your suggestion, and we can deal with
> divergence of IResource if/when that ever happens.
>
> Jim
>
> >>> Greg Byrd <gbyrd@xxxxxxxx> 9/20/06 7:11 AM >>>
>
> So how about making IDigitalSubject a sub-interface of IResource? I
> don't see the need for another interface type that has no other uses,
> and IResource doesn't add anything to IEntity anyway, except for also
> implementing IHasMetadata.
>
> ...Greg
>
>
> Jim Sermersheim wrote:
> > Oops, we were talking about it on the #higgins chat channel, and I
> > forgot it wasn't discussed here.
> >
> > Well, not much of a debate. I added IResource and ILiteral interfaces
> > sometime back (for attribute value types). Today I finally got around
> > to fleshing out IResource and noticed for the second time that it's
> > almost exactly like IDigitalSubject (just doesn't have a Context). So
> > rather that duplicating the APIs having to do with attributes, name,
> > and type, I proposed a super-interface for tha t.
> >
> > We debated between IObject and IEntity. I'm open to other names or
> > solutions if they're better.
> >
> > Jim
> >
> > >>> Greg Byrd <gbyrd@xxxxxxxx> 9/19/06 6:32 PM >>>
> >
> > So I missed this debate -- what's the reason for the change to IEntity?
> >
> > ...Greg
> >
> >
> > Jim Sermersheim wrote:
> > > For all you cont ext provider writers out there, I forgot to tell you
> > > that as part of the creation of the more generic IEntity, the method
> > > name changed (was IDigitalSubject.getUniqueID, is now
> > > IEntity.getName). In terms of its use on IDigitalSubject, it's still
> > > the Contextually Unique Identifier. I suppose that's true for its use
> > > on IResource as well. Hmm, maybe I should have left the name
> > > alone... Opinions?
> > >
> > > Jim
> > >
> >
> > _ ______________________________________________
> > 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_______________________________________________
higgins-dev mailing list
higgins-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/higgins-dev

GIF image

GIF image

GIF image


Back to the top