On Thu, Dec 17, 2009 at 11:07 PM, Sergiu Dumitriu <ser...@xwiki.com> wrote:
> On 12/17/2009 10:30 PM, Pascal Voitot wrote: > > If you look in semantic web definitions, the difference between an entity > > and a resource is really hard to tell:) > > Entity seems to be the most generic word to describe something that > exists > > or has existed. > > On wikipedia, i found this definition: > > A *resource* is any physical or virtual entity of limited availability, > or > > anything used to help one earn a living.[*citation > > needed<http://en.wikipedia.org/wiki/Wikipedia:Citation_needed> > > *] In most cases, commercial or even ethic factors require resource > > allocation<http://en.wikipedia.org/wiki/Resource_allocation> through > resource > > management<http://en.wikipedia.org/wiki/Resource_management>. > > I also tend to associate Resource with something that can be measured > and priced, like water or wood. > > > But I don't really like entity because nowadays, this is really > associated > > to a "persisted" entity and no more to a thing of any type... > > How come? Why do you associate the "persisted" feature? And isn't it > good, since the model will be persisted in the storage? > > Tell any java developer:"entity" and he will speak about persistence :)... But you're right, it's not so bad. Anyway, entity always gives me the impression of dealing with "some thing". You know in french we have a word to represent anything: we say "truc"... entity is a bit like that ;) > > Pascal > > > > On Thu, Dec 17, 2009 at 9:31 PM, Caleb James DeLisle< > > calebdeli...@lavabit.com> wrote: > > > >> Hi, > >> > >> Big +1 for getUUID() and storing UUID as byte[] and returning > >> java.util.UUID > >> Storage as byte[] will improve db load times. > >> > >> Whatever you like for a name is fine for me but I would caution against > >> over > >> generic words such as "Model", "Context", "Factory", and "Manager" > because > >> when I first began reading the source, I often found these terms > unhelpful. > >> > >> Perhaps ObjectReference instead of ModelReference? This would make sense > >> if and when Document, Space, Attachment, and Wiki extend Object. > >> > >> Caleb > >> > >> Vincent Massol wrote: > >>> On Dec 17, 2009, at 3:08 PM, Fabio Mancinelli wrote: > >>> > >>>> On Dec 17, 2009, at 1:48 PM, Vincent Massol wrote: > >>>> > >>>>> Proposal > >>>>> ======= > >>>>> > >>>>> I'd like to propose ModelReference for the base object and then > >>>>> DocumentReference, SpaceReference, WikiReference, > >>>>> AttachmentReference. > >>>>> Note: This is different from Identity which is unique (a UUID). > >>>>> References do not point to unique objects. > >>>>> > >>>> I am not sure of having understood the note. In particular what you > >>>> mean when you say "references do not point to unique objects" > >>> > >>> The way I view it is that an object (or Entity or Resource) will have > >>> 2 methods: > >>> - getReference() (corresponds to Node.getPath() in JCR I believe) > >>> - getUUID() > >>> > >>> In other words, it's possible to have several References pointing to > >>> the same object (or Entity or Resource). This is very useful for > >>> implementing renames for example. > >>> > >>> In addition, FTM I'm not sure if a Reference should include the version > >>> > >>> I need for think a bit more about this since I'm not 100% sure. If you > >>> have ideas let me know. > >>> > >>> Thanks > >>> -Vincent > >>> > >>>>> Reference makes sense to me since it means what it means... :) > >>>>> For example the API: Document getDocument(DocumentReference) is > >>>>> pretty > >>>>> clear IMO. > >>>>> > >>>> I would say ResourceReference for the base object > >>>> and DocumentReference, SpaceReference, WikiReference, > >>>> AttachmentReference for the specific resource type references. > > > -- > Sergiu Dumitriu > http://purl.org/net/sergiu/ > _______________________________________________ > devs mailing list > devs@xwiki.org > http://lists.xwiki.org/mailman/listinfo/devs > _______________________________________________ devs mailing list devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs