jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Mazzocchi <stef...@apache.org>
Subject Re: [PROPOSAL] Public NodeType Library (pntl)
Date Sat, 30 Oct 2004 17:50:13 GMT
David Nuescheler wrote:

> hi guys,
> since jsr-170 does not mandate a particular set of 
> nodetypes, beyond what is used internally to the
> repository, i would like to propose to create a public
> place where people can share the nodetype that 
> they use in their content repository applications.
> i think this could also allow applications to interact
> in a smarter and more direct way, that go beyond the
> basic "content repository plumbing" provided by 
> jsr-170.
> therefore i would like to propose a structure that
> allows everybody to first publish their nodetypes
> easily, and then this might give the community
> the possibility to maybe agree on some 
> "well-known" or "endorsed" nodetypes for 
> particular interest groups.
> [ similar to ldaps objectclasses
> http://www-eleves.int-evry.fr/~deckmyn/docs/LDAP-ObjectClasses.html ]
> i think we might have a first starting point, with
> respect to things like content management, 
> where we could be able to agree between
> a couple of groups that are active on this list
> to come to a certain consensus on content
> models.
> initially, i could see four levels of nodetypes:
> ---
> (1) private:
> the nodetype definition is proprietary and
> not part publically published in the nodetype
> library.
> (2) published:
> the nodetype definition is published by but
> not agreed upon as being well-known, since
> there is not consensus that the content
> model is general enough to interest 
> multiple groups of application developers.
> everybody might be able to publish nodetype
> definitions.
> (3) well-known:
> a group of independant developers has agreed
> upon a fundamental content model. i would
> assume that "well-known" nodetypes should
> make a good starting point for specializing
> nodetypes for a particular application.
> (4) spec / mandatory:
> the mandatory nodetypes are specified by the
> jsr-170 and can be used by any jsr-170 application.
> ---
> any comments?


not a negative vote, but a word of warning: so far, JCR has avoided 
(intelligently, I might add) the "ontological" problem by following your 
lead in the idea that metadata is data and therefore should not exhibit 
difference at the API level.

This allowed the working group to arrive at the spec without major 
'ontological harmonization' debates (well, query syntax aside, which is, 
in fact, an instance of this).

EbXML, for example, did not follow such a smart separation approach and 
is very likely to fail miserably to gain consensus, exactly because of this.

Now, you are proposing to enter the ontological realm. I completely 
agree that this is a required move: without a conceptual model of the 
data, it's impossible to write programs that use it, but, at the same 
time, and this is my day job, let me outline a few mistakes that people 
normally do and that might be avoided if we start with the right foot.

There are two approaches to ontological harmonization: "thou shall use 
mine" and "be strict in what you use for yourself, be flexible on what 
you accept from others".

I call the first, half joking, the "bush approach" and the second the 
"postel approach".

The first leads to wars, the second leads to internets.

In respect to JCR, there are few important things to say:

  1) don't try to approach semantic interoperability across different 
containers. this is not your job, and this is not the right place, just 
focus on what you need to have done in order to make your life easier.

  2) don't care about semantic interoperability but *DO CARE* about 
unique identification of concepts. Unique identification is the 
foundation of symbolic representation. In short, this means: use 
namespaces and use good future-proof technology/vendor-neutral URIs for 
them as much as possible.

  3) don't overspecify: do the simplest thing that get your job done and 
allow others to do the same.

> to give an example of what direction i am thinking in:
> ---
> pntl:image extends nt:mimeResource
>  pntl:height        long
>  pntl:width         long
> pntl:document 
>  pntl:author        string, reference?, multiple?
>  pntl:title         string
>  pntl:description   string
>  pntl:image         nt:image
> pntl:user
>  pntl:userId        string
>  pntl:password      string
>  pntl:fullname      string
>  pntl:email         string

my strong suggestion would be to use Dublin Core as a starting point for 
extrinsic metadata about objects.


View raw message