You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@jackrabbit.apache.org by David Nuescheler <da...@gmail.com> on 2004/10/30 16:41:31 UTC
[PROPOSAL] Public NodeType Library (pntl)
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?
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
---
regards,
david
----------------------------------------------------------------------
standardize your content-repository !
http://www.jcp.org/en/jsr/detail?id=170
---------------------------------------< david.nuescheler@day.com >---
This message is a private communication. If you are not the intended
recipient, please do not read, copy, or use it, and do not disclose it
to others. Please notify the sender of the delivery error by replying
to this message, and then delete it from your system. Thank you.
The sender does not assume any liability for timely, trouble free,
complete, virus free, secure, error free or uninterrupted arrival of
this e-mail. For verification please request a hard copy version.
mailto:david.nuescheler@day.com
http://www.day.com
David Nuescheler
Chief Technology Officer
Day Software AG
Barfuesserplatz 6 / Postfach
4001 Basel
Switzerland
T 41 61 226 98 98
F 41 61 226 98 97
Re: [PROPOSAL] Public NodeType Library (pntl)
Posted by David Nuescheler <da...@gmail.com>.
hi david,
> This is a very interesting discussion. However, I propose that we discuss
> things like this on the standard EG email list.
> This is the TCK email list right? This seems more like an EG
> discussion than a TCK discussion.
jackrabbit is amongst other things also hosting the tck and
the ri. however, primarily it is an opensource repository
implementation, and therefore will define many things that are
outside the scope of the jsr-170 spec.
this includes implementation details such as how to register a
nodetype, how to manage users, access control or workspaces.
nodetypes for those and other content repository
internals and applications is not something that should
be mandated through jsr-170, and therefore those
discussions should not concern the expert group
directly.
of course every member of the expert group is and
has been cordially invited to join the discussions in
the jackrabbit-dev list.
regards,
david
----------------------------------------------------------------------
standardize your content-repository !
http://www.jcp.org/en/jsr/detail?id=170
---------------------------------------< david.nuescheler@day.com >---
This message is a private communication. If you are not the intended
recipient, please do not read, copy, or use it, and do not disclose it
to others. Please notify the sender of the delivery error by replying
to this message, and then delete it from your system. Thank you.
The sender does not assume any liability for timely, trouble free,
complete, virus free, secure, error free or uninterrupted arrival of
this e-mail. For verification please request a hard copy version.
mailto:david.nuescheler@day.com
http://www.day.com
David Nuescheler
Chief Technology Officer
Day Software AG
Barfuesserplatz 6 / Postfach
4001 Basel
Switzerland
T 41 61 226 98 98
F 41 61 226 98 97
Re: Lenya workflow and OWL [was Re: [PROPOSAL] Public NodeType
Library (pntl)]
Posted by Rolf Kulemann <ro...@apache.org>.
On Wed, 2004-11-03 at 20:01, Rolf Kulemann wrote:
> On Mon, 2004-11-01 at 00:24, Stefano Mazzocchi wrote:
> > Rolf Kulemann wrote:
> >
> > > My idea is to describe the concept of workflow using OWL/RDF.
> >
OWL/semantic web references for those who are interested:
*
http://www.kbs.uni-hannover.de/~henze/semweb04/skript/slides/7_6_2004/Chapter4.ppt
* http://www.w3.org/DesignIssues/Semantic.html
* http://www.w3.org/TR/2004/REC-owl-features-20040210/
* http://www.w3.org/2001/sw/WebOnt/
*
http://www.ksl.stanford.edu/people/dlm/papers/ontology101/ontology101-noy-mcguinness.html
and many more...
--
Rolf Kulemann
---------------------------------------------------------------------
To unsubscribe, e-mail: lenya-dev-unsubscribe@cocoon.apache.org
For additional commands, e-mail: lenya-dev-help@cocoon.apache.org
Re: Lenya workflow and OWL [was Re: [PROPOSAL] Public NodeTypeLibrary (pntl)]
Posted by Andreas Kuckartz <A....@ping.de>.
> > Apache Lenya might want to collaborate with Apache Agila (the BPM project
> > currently in the incubator) regarding workflow.
>
> Is there any need for extending/replacing the current workflow
> engine in Lenya?
I do think that the current workflow is appropriate for most purposes and does
not need to be replaced. But in some organisations workflow is more important
than other aspects of content management. That is why I am suggesting to keep an
eye on the mentioned project and keep Lenya's workflow replaceable.
The interfaces of Apache Agila are not fixed yet. It therefore probably is
easier to influence them now. (In fact there is not even any code available at
the moment.)
Andreas
---------------------------------------------------------------------
To unsubscribe, e-mail: lenya-dev-unsubscribe@cocoon.apache.org
For additional commands, e-mail: lenya-dev-help@cocoon.apache.org
Re: Lenya workflow and OWL [was Re: [PROPOSAL] Public
NodeTypeLibrary (pntl)]
Posted by Rolf Kulemann <ro...@apache.org>.
On Thu, 2004-11-04 at 09:31, Andreas Hartmann wrote:
> Andreas Kuckartz wrote:
> >>>>Even if the interoperability is still a dream, it doesn't hurt to use
> >>>>OWL/RDF as workflow metadata tools, it's just XML, which we use anyhow.
> >>>>
> >>>>I now could give you some OWL examples how we could model the workflow
> >>>>and the underlying state machine, but I'm really tyred, eh tired.
> >
> >
> > Apache Lenya might want to collaborate with Apache Agila (the BPM project
> > currently in the incubator) regarding workflow.
>
> Is there any need for extending/replacing the current workflow
> engine in Lenya?
IMHO our workflow is quite flexible, simple and useful. I'm just talking
about the form of the meta data.
Sorry for the confusion.
--
Rolf Kulemann
---------------------------------------------------------------------
To unsubscribe, e-mail: lenya-dev-unsubscribe@cocoon.apache.org
For additional commands, e-mail: lenya-dev-help@cocoon.apache.org
Re: Lenya workflow and OWL [was Re: [PROPOSAL] Public NodeTypeLibrary
(pntl)]
Posted by Andreas Hartmann <an...@apache.org>.
Andreas Kuckartz wrote:
>>>>Even if the interoperability is still a dream, it doesn't hurt to use
>>>>OWL/RDF as workflow metadata tools, it's just XML, which we use anyhow.
>>>>
>>>>I now could give you some OWL examples how we could model the workflow
>>>>and the underlying state machine, but I'm really tyred, eh tired.
>
>
> Apache Lenya might want to collaborate with Apache Agila (the BPM project
> currently in the incubator) regarding workflow.
Is there any need for extending/replacing the current workflow
engine in Lenya?
-- Andreas
---------------------------------------------------------------------
To unsubscribe, e-mail: lenya-dev-unsubscribe@cocoon.apache.org
For additional commands, e-mail: lenya-dev-help@cocoon.apache.org
Re: Lenya workflow and OWL [was Re: [PROPOSAL] Public NodeTypeLibrary (pntl)]
Posted by Andreas Kuckartz <A....@ping.de>.
> > > Even if the interoperability is still a dream, it doesn't hurt to use
> > > OWL/RDF as workflow metadata tools, it's just XML, which we use anyhow.
> > >
> > > I now could give you some OWL examples how we could model the workflow
> > > and the underlying state machine, but I'm really tyred, eh tired.
Apache Lenya might want to collaborate with Apache Agila (the BPM project
currently in the incubator) regarding workflow.
One could or should think about an extension of Content Management to Semantic
Web (Content) Management. In that context OWL can be relevant.
Andreas
---------------------------------------------------------------------
To unsubscribe, e-mail: lenya-dev-unsubscribe@cocoon.apache.org
For additional commands, e-mail: lenya-dev-help@cocoon.apache.org
Re: Lenya workflow and OWL [was Re: [PROPOSAL] Public NodeType
Library (pntl)]
Posted by Rolf Kulemann <ro...@apache.org>.
On Wed, 2004-11-03 at 22:38, Stefano Mazzocchi wrote:
> Rolf Kulemann wrote:
...
> > This, yeah, hopefully Lenya independent, abstract concepts can be
> > used/extended by other JCR apps to interoperate with out JCR repo
> > layout. ....I'm dreaming, I know. IMHO this is the only way to promote
> > Lenya to more than _ another CMS only _
> >
> > Stefano, is this idea too naiv? I'm no semantic web expert, yet.
> >
> > Even if the interoperability is still a dream, it doesn't hurt to use
> > OWL/RDF as workflow metadata tools, it's just XML, which we use anyhow.
> >
> > I now could give you some OWL examples how we could model the workflow
> > and the underlying state machine, but I'm really tyred, eh tired.
> >
> > Gimme your opinion please :)
>
> I think this is just plain useless complication for no reason.
>
> My suggestion is: do the simplest thing that can possible solve the
> problem that you have, right here and right now, everything else is
> overshooting.
Thanks for your reply.
Why do you think so? Don't you believe in the interoperability which can
be achieved with SW tech?
People are complaining, that Lenya is just another CMS. And I think the
overhead is not that huge using RDF and OWL, since we simply use XML for
annotation as before. So where is the overshoot? The difference that we
have some new namespaces and OWL definitions somewhere.
I will have your opinion in mind, but it will not keep me away from
experimenting. There are too much papers about SW and only few
solutions. Paperwork is not my business. I want to try it out. Maybe
Lenya is not the right place, but it is a real world show case and it
will separate Lenya from all the other CMSs I know.
Would you mind to give some more arguments why you think it is an
overshoot?
I'm really interested in your opinion. Do not hesitate telling/arguing
me I'm thinking too naive. It is important for me to get on the right
way and other honest opinions are always helping me.
--
Rolf Kulemann
---------------------------------------------------------------------
To unsubscribe, e-mail: lenya-dev-unsubscribe@cocoon.apache.org
For additional commands, e-mail: lenya-dev-help@cocoon.apache.org
Re: Lenya workflow and OWL [was Re: [PROPOSAL] Public NodeType
Library (pntl)]
Posted by Rolf Kulemann <ro...@apache.org>.
On Wed, 2004-11-03 at 22:38, Stefano Mazzocchi wrote:
> Rolf Kulemann wrote:
>
> > On Mon, 2004-11-01 at 00:24, Stefano Mazzocchi wrote:
> >
> >>Rolf Kulemann wrote:
> >>
> >>
> >>>My idea is to describe the concept of workflow using OWL/RDF.
> >>
> >>why?
> >
> >
> >
> > JCR is like JDBC; a low level _backend_ access layer, right? I assume
> > that. That means interoperability of JCR apps is as restricted as of
> > JDBC based apps; App A does not now the semantic meaning of tables in a
> > DB model of App B, right? I think so. Let table "Person" be a table in
> > the database of App B.
> >
> > The only way around that is to describe semantically, that table
> > "Person" _describes persons_. The same matches to nodes and properties
> > in JCR, IMHO.
> >
> > If another CMS app than Lenya should now what property belongs to
> > workflow, we need to describe _semantically_: this property belongs to
> > workflow and the node it is attached to is a , lets say, document.
> >
> > I thought I can do that using OWL (full or light dunno yet what is
> > appropriate yet).
> >
> > This means more concrete: Lets use OWL classes and properties to
> > describe/model/define our concepts, aka ontologies, with OWL. Instances
> > of these classes are attached as workflow _metadata_ to appropriate
> > nodes.
> >
> > This, yeah, hopefully Lenya independent, abstract concepts can be
> > used/extended by other JCR apps to interoperate with out JCR repo
> > layout. ....I'm dreaming, I know. IMHO this is the only way to promote
> > Lenya to more than _ another CMS only _
> >
> > Stefano, is this idea too naiv? I'm no semantic web expert, yet.
> >
> > Even if the interoperability is still a dream, it doesn't hurt to use
> > OWL/RDF as workflow metadata tools, it's just XML, which we use anyhow.
> >
> > I now could give you some OWL examples how we could model the workflow
> > and the underlying state machine, but I'm really tyred, eh tired.
> >
> > Gimme your opinion please :)
>
> I think this is just plain useless complication for no reason.
Why?
--
Rolf Kulemann
---------------------------------------------------------------------
To unsubscribe, e-mail: lenya-dev-unsubscribe@cocoon.apache.org
For additional commands, e-mail: lenya-dev-help@cocoon.apache.org
Re: Lenya workflow and OWL [was Re: [PROPOSAL] Public NodeType Library
(pntl)]
Posted by Stefano Mazzocchi <st...@apache.org>.
Rolf Kulemann wrote:
> On Mon, 2004-11-01 at 00:24, Stefano Mazzocchi wrote:
>
>>Rolf Kulemann wrote:
>>
>>
>>>My idea is to describe the concept of workflow using OWL/RDF.
>>
>>why?
>
>
>
> JCR is like JDBC; a low level _backend_ access layer, right? I assume
> that. That means interoperability of JCR apps is as restricted as of
> JDBC based apps; App A does not now the semantic meaning of tables in a
> DB model of App B, right? I think so. Let table "Person" be a table in
> the database of App B.
>
> The only way around that is to describe semantically, that table
> "Person" _describes persons_. The same matches to nodes and properties
> in JCR, IMHO.
>
> If another CMS app than Lenya should now what property belongs to
> workflow, we need to describe _semantically_: this property belongs to
> workflow and the node it is attached to is a , lets say, document.
>
> I thought I can do that using OWL (full or light dunno yet what is
> appropriate yet).
>
> This means more concrete: Lets use OWL classes and properties to
> describe/model/define our concepts, aka ontologies, with OWL. Instances
> of these classes are attached as workflow _metadata_ to appropriate
> nodes.
>
> This, yeah, hopefully Lenya independent, abstract concepts can be
> used/extended by other JCR apps to interoperate with out JCR repo
> layout. ....I'm dreaming, I know. IMHO this is the only way to promote
> Lenya to more than _ another CMS only _
>
> Stefano, is this idea too naiv? I'm no semantic web expert, yet.
>
> Even if the interoperability is still a dream, it doesn't hurt to use
> OWL/RDF as workflow metadata tools, it's just XML, which we use anyhow.
>
> I now could give you some OWL examples how we could model the workflow
> and the underlying state machine, but I'm really tyred, eh tired.
>
> Gimme your opinion please :)
I think this is just plain useless complication for no reason.
My suggestion is: do the simplest thing that can possible solve the
problem that you have, right here and right now, everything else is
overshooting.
--
Stefano.
Lenya workflow and OWL [was Re: [PROPOSAL] Public NodeType Library
(pntl)]
Posted by Rolf Kulemann <ro...@apache.org>.
On Mon, 2004-11-01 at 00:24, Stefano Mazzocchi wrote:
> Rolf Kulemann wrote:
>
> > My idea is to describe the concept of workflow using OWL/RDF.
>
> why?
JCR is like JDBC; a low level _backend_ access layer, right? I assume
that. That means interoperability of JCR apps is as restricted as of
JDBC based apps; App A does not now the semantic meaning of tables in a
DB model of App B, right? I think so. Let table "Person" be a table in
the database of App B.
The only way around that is to describe semantically, that table
"Person" _describes persons_. The same matches to nodes and properties
in JCR, IMHO.
If another CMS app than Lenya should now what property belongs to
workflow, we need to describe _semantically_: this property belongs to
workflow and the node it is attached to is a , lets say, document.
I thought I can do that using OWL (full or light dunno yet what is
appropriate yet).
This means more concrete: Lets use OWL classes and properties to
describe/model/define our concepts, aka ontologies, with OWL. Instances
of these classes are attached as workflow _metadata_ to appropriate
nodes.
This, yeah, hopefully Lenya independent, abstract concepts can be
used/extended by other JCR apps to interoperate with out JCR repo
layout. ....I'm dreaming, I know. IMHO this is the only way to promote
Lenya to more than _ another CMS only _
Stefano, is this idea too naiv? I'm no semantic web expert, yet.
Even if the interoperability is still a dream, it doesn't hurt to use
OWL/RDF as workflow metadata tools, it's just XML, which we use anyhow.
I now could give you some OWL examples how we could model the workflow
and the underlying state machine, but I'm really tyred, eh tired.
Gimme your opinion please :)
--
Rolf Kulemann
---------------------------------------------------------------------
To unsubscribe, e-mail: lenya-dev-unsubscribe@cocoon.apache.org
For additional commands, e-mail: lenya-dev-help@cocoon.apache.org
Re: [PROPOSAL] Public NodeType Library (pntl)
Posted by Stefano Mazzocchi <st...@apache.org>.
Rolf Kulemann wrote:
> My idea is to describe the concept of workflow using OWL/RDF.
why?
--
Stefano, curious not criticizing.
Re: [PROPOSAL] Public NodeType Library (pntl)
Posted by Rolf Kulemann <ro...@apache.org>.
On Sun, 2004-10-31 at 12:48, Rolf Kulemann wrote:
...
>
> My idea is to describe the concept of workflow using OWL/RDF.
>
> Lets say we have (OWL) classes: WorkflowEvent, WorkflowState and
> WorkflowTransition. Instances of those are attached as meta information
> to a document node, however.
Having that said, the OWL approach goes on with describing the concept
of a general state machine with OWL/RDF. This is then extended/used for
the workflow concept. We in Lenya land have made good experience with
modeling the workflow as a state machine. It is simple and still
flexible.
Would this make sense?
--
Rolf Kulemann
Re: [PROPOSAL] Public NodeType Library (pntl)
Posted by Rolf Kulemann <ro...@apache.org>.
On Sun, 2004-10-31 at 12:07, David Nuescheler wrote:
> hi rolf,
>
> > Interesting discussion here. I have to admit I'm not a semantic web
> > profi, but we/I in Lenya land have the idea to describe things like
> > workflow (and maybe other parts) with, eh, ontologies. We then would use
> > those _conceptual_ metadata to describe workflow of documents.
> > This is just a draft idea maybe only living in my head, and I'm not sure
> > if we should attach the wf meta data direct to document nodes or keep
> > them separate. We aren't that far in that discussion, yet.
>
> i think the workflow would be a very interesting topic to agree upon.
> since it has a very limited scope. i would also not call it meta information
> it is just application data in my mind and the application happens to be a
> "workflow" application.
Well, ok, I meant I have in mind to model the workflow "info data" as
meta data attached to special node types; lets say content or document
nodes. Maybe I have not enough knowledge about JCR, yet, and I'm wrong
here.
My idea is to describe the concept of workflow using OWL/RDF.
Lets say we have (OWL) classes: WorkflowEvent, WorkflowState and
WorkflowTransition. Instances of those are attached as meta information
to a document node, however. As I said, only draft ideas, since I have
to do other work ATM.
Using an OWL/RDF based approach would also make it possible to integrate
workflow info into other applications equivalence classes (right term?).
This bridges the gap between the _lowlevelness_ of JCR and specific
applications like CMSs.
>
> currently we (day software) model our workflow in a fashion that
> is directly attached to the "document" (well, content really... ).
It has some advantages like if you move a doc, all closely related info
is also moved (workflow info). Otherwise you would have to maintain
links or such.
>
> i think it should not be too difficult to model a nodetype that could
> be directly attached as a mixin to a document or just refer to it.
Eh, ok, I have to read the JCR spec a bit more detailed. I'm really a
rookie and sometimes naiv.
>
> i would be very interested in having a discussion thread to
> see if we can reach any consensus on a minimal "workflow"
> nodetype that we could use as an example workflow model
> in our applications... anybody interested?
Definitely.
--
Rolf Kulemann
Re: [PROPOSAL] Public NodeType Library (pntl)
Posted by Stefano Mazzocchi <st...@apache.org>.
David B Victor wrote:
> This is a very interesting discussion. However, I propose that we discuss
> things like this on the standard EG email list. This is the TCK email
> list right?
No, it's not. This is an apache list about an open source project that
is incubating with the objective to implement the JSR 170 specification.
Whether or not the JSR 170 group uses the outcome of this project as the
official RI and TCK, that's another matter entirely and it's not a
concern for the ASF in general.
> This seems more like an EG discussion than a TCK discussion.
As I wrote, I strongly think that the benefit of the JSR 170 spec is
that it does not deal with ontological specification of the metadata.
Do you want to have another query language fight over the ontology for
workflow definitions? what about the taxonomy of user groups?
I don't.
--
Stefano.
Re: [PROPOSAL] Public NodeType Library (pntl)
Posted by David B Victor <db...@us.ibm.com>.
This is a very interesting discussion. However, I propose that we discuss
things like this on the standard EG email list. This is the TCK email
list right? This seems more like an EG discussion than a TCK discussion.
Thank You,
David B. Victor
IBM Silicon Valley
dbvictor@us.ibm.com
408-463-2788
David Nuescheler <da...@gmail.com>
10/31/2004 03:07 AM
Please respond to jackrabbit-dev
To: jackrabbit-dev@incubator.apache.org
cc:
Subject: Re: [PROPOSAL] Public NodeType Library (pntl)
hi rolf,
> Interesting discussion here. I have to admit I'm not a semantic web
> profi, but we/I in Lenya land have the idea to describe things like
> workflow (and maybe other parts) with, eh, ontologies. We then would use
> those _conceptual_ metadata to describe workflow of documents.
> This is just a draft idea maybe only living in my head, and I'm not sure
> if we should attach the wf meta data direct to document nodes or keep
> them separate. We aren't that far in that discussion, yet.
i think the workflow would be a very interesting topic to agree upon.
since it has a very limited scope. i would also not call it meta
information
it is just application data in my mind and the application happens to be a
"workflow" application.
currently we (day software) model our workflow in a fashion that
is directly attached to the "document" (well, content really... ).
i think it should not be too difficult to model a nodetype that could
be directly attached as a mixin to a document or just refer to it.
i would be very interested in having a discussion thread to
see if we can reach any consensus on a minimal "workflow"
nodetype that we could use as an example workflow model
in our applications... anybody interested?
regards,
david
Re: [PROPOSAL] Public NodeType Library (pntl)
Posted by David Nuescheler <da...@gmail.com>.
hi rolf,
> Interesting discussion here. I have to admit I'm not a semantic web
> profi, but we/I in Lenya land have the idea to describe things like
> workflow (and maybe other parts) with, eh, ontologies. We then would use
> those _conceptual_ metadata to describe workflow of documents.
> This is just a draft idea maybe only living in my head, and I'm not sure
> if we should attach the wf meta data direct to document nodes or keep
> them separate. We aren't that far in that discussion, yet.
i think the workflow would be a very interesting topic to agree upon.
since it has a very limited scope. i would also not call it meta information
it is just application data in my mind and the application happens to be a
"workflow" application.
currently we (day software) model our workflow in a fashion that
is directly attached to the "document" (well, content really... ).
i think it should not be too difficult to model a nodetype that could
be directly attached as a mixin to a document or just refer to it.
i would be very interested in having a discussion thread to
see if we can reach any consensus on a minimal "workflow"
nodetype that we could use as an example workflow model
in our applications... anybody interested?
regards,
david
Re: [PROPOSAL] Public NodeType Library (pntl)
Posted by Rolf Kulemann <ro...@apache.org>.
On Sun, 2004-10-31 at 10:41, David Nuescheler wrote:
> hi stefano
...
>
> > 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.
> sounds great.
>
> > my strong suggestion would be to use Dublin Core as a starting point for
> > extrinsic metadata about objects.
> yep, forgot about that... (scrap my prior suggestions)
> dc sounds like a perfect starting point for meta-data to me.
> thanks.
Interesting discussion here. I have to admit I'm not a semantic web
profi, but we/I in Lenya land have the idea to describe things like
workflow (and maybe other parts) with, eh, ontologies. We then would use
those _conceptual_ metadata to describe workflow of documents.
This is just a draft idea maybe only living in my head, and I'm not sure
if we should attach the wf meta data direct to document nodes or keep
them separate. We aren't that far in that discussion, yet.
I'm curious about your opinions, if my idea is totally silly or if you
guys think it is a worthwhile approach to follow.
--
Rolf Kulemann
Re: [PROPOSAL] Public NodeType Library (pntl)
Posted by David Nuescheler <da...@gmail.com>.
hi stefano
> 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.
i completely agree.
my intention is certainly the latter, thats also why i tried to avoid having
those discussions in the specification process of jcr. i do not believe
that ontological conformity can be mandated in a successful way.
> 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.
sounds great.
> my strong suggestion would be to use Dublin Core as a starting point for
> extrinsic metadata about objects.
yep, forgot about that... (scrap my prior suggestions)
dc sounds like a perfect starting point for meta-data to me.
thanks.
regards,
david
----------------------------------------------------------------------
standardize your content-repository !
http://www.jcp.org/en/jsr/detail?id=170
---------------------------------------< david.nuescheler@day.com >---
This message is a private communication. If you are not the intended
recipient, please do not read, copy, or use it, and do not disclose it
to others. Please notify the sender of the delivery error by replying
to this message, and then delete it from your system. Thank you.
The sender does not assume any liability for timely, trouble free,
complete, virus free, secure, error free or uninterrupted arrival of
this e-mail. For verification please request a hard copy version.
mailto:david.nuescheler@day.com
http://www.day.com
David Nuescheler
Chief Technology Officer
Day Software AG
Barfuesserplatz 6 / Postfach
4001 Basel
Switzerland
T 41 61 226 98 98
F 41 61 226 98 97
Re: [PROPOSAL] Public NodeType Library (pntl)
Posted by Stefano Mazzocchi <st...@apache.org>.
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?
David,
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.
--
Stefano.