Hi all,
I want to share the ideas that are emerged from our talk with Rupert
about CMS Adapter. I will appreciate your further ideas and comments.
Its current documentation is available at [1]. As a summary, main
functionality of this component is generating a ontology based on the
structure of a CMS. It uses predefined bridges to generate the ontology
e.g ConceptBridge is used generate class hierarchy and InstanceBridge is
used generate individuals.
We would like to improve this component in the following ways:
1) For the time being it uses a model generated from an XSD Schema to
represent CMS nodes We decided to add an RDF processing mechanism.
First, we will define a simple vocabulary representing CMS nodes.
2) There will be bidirectional bridges meaning that it will be possible
to update content management system based on the RDF data and bridges.
Having the following data,
<node1> rdf:type vCard:Event
<node1> rdfs:label "Community Workshop Paris"
<node1> vCard:participant <node2>
<node2> rdf:type vCard:Agent
<node2> rdfs:label "SRDC"
Thanks to a bridge definitions vCard:Event and vCard:Agent typed
resources will be created nodes in CMS and an hierarchy between them can
be set. This will be done by first annotating RDF with cms vocabulary
and then storing it to CMS. If a CMS node already exists, it will be
updated with the new annotations. cms vocabulary annotated RDF would be
like the following:
<node1> rdf:type cms:Node
<node1> cms:path "{path}"
<node1> rdf:type vCard:Event
<node1> rdfs:label "Community Workshop Paris"
<node1> vCard:participant <node2>
<node2> rdf:type cms:Node
<node2> cms:parent <node1>
<node2> cms:path "{path}"
<node2> rdf:type vCard:Agent
<node2> rdfs:label "SRDC"
I attach the raw discussion at the bottom of the mail.
Best,
Suat
[1] http://wiki.iks-project.eu/index.php/CMS_Adaptor
IRC #stanbol 2011-07-28
08:09
suat
westei I was thinking about the RDF representation of content items that
are supplied to CMS Adapter, but I could not decide whether I should
directly reflect our current model to RDF or assume that they can be
represented with a set of triples having same subject and any custom
predicates?
08:09
suat
What was the idea you had in your mind in Paris?
08:10
westei
thats a good question
08:10
suat
Because representing CMS objects in our model it seems not to be an easy way
08:10
westei
What is "our model"?
the current XSD for the CMS Adapter converted in RDF?
08:10
suat
the model generated from xsd
yes
08:11
westei
Lets not think in "models" but in Usage Scenarios
maybe this helps
having a 1:1 mapping of the CMS to RDF would make it easy to implement
the CMS Adapter, but one would need to write Processors for each and
every CMS
As we want to bring semantic capabilities to CMS we are intersted in:
* the structure of the CMS (hierarchy, links, ...)
* storing Knowledge to the CMS (basically JSON-LD like stuff) and
mapping them to hierarchy, links, paths ...
* maybe storing knowledge (ala "named graphs") as Document (serialized
RDF graph) in the CMS
* retrieving Documents + metadata from the CMS and enhancing them
any more?
08:18
suat
those are good points.
but they seem a bit high level for me
while mapping hierarchy and links to an ontology for example
08:20
westei
The CMS Adapter has several internal functionalities/components
08:20
suat
again the representation of CMS in RDF is not clear for me
08:20
westei
* the thing that connects to the CMS (incl. the RESTful Service CMS can
connect)
* the component that converts this to the XSD (in future RDF)
* the procesors that convert the data and send it to the target
correct?
08:21
suat
yes
when first executing bridges for JCR and CMIS it is not necessary to
provide any input in XSD model
according path in the bridge definition objects are retrieved from CMS
directly
in case of any update or delete we expect input in XSD model for the
time being
08:24
westei
ok than replace the XSD in the second line with an Java Object Model and
add the XSD stuff to the RESTful service
but because of the Java Object Model is a JAXB generated one - for me it
is the same
To support all above use cases this workflow needs to be bidirectional
I think the CMS Adapter should come with a "RDF schema" that can
describe typically CMS things
like the jcr namespace
this would replace the current XSD schema (i guess)
08:29
suat
I started create such a schema mainly based on the fields of object in
the current model
for example a cmsobject has a uniqueID, localName, path, properties,
children
08:29
westei
At least the RESTful service would need it anyway
One would need to have a detailed look on that
08:30
suat
but it seemed to me to represent CMS objects in this way would require
same effort with creating an ontology from the CMS
08:30
westei
e.g. do you really need "property"=
properties are outgoing rdf triples
children are also outgoing rdf triples
08:31
suat
I wanted clarify this representation actually in my initial question
08:32
westei
so we come back to the point where the Rubber hits the Road ^^
08:32
suat
then you see CMS objects as a set of triples having same subject and
custom predicates
08:32
westei
I think so
e.g. a node with a children node could be represented in rdf like
<node1> rdf:type cms:Node
<node1> cms:path "{path}"
<node1> rdf:type vCard:Event
<node1> rdfs:label "Community Workshop Paris"
<node1> vCard:participant <node2>
<node2> rdf:type cms:Node
<node2> cms:parent <node1>
<node2> cms:path "{path}"
<node2> rdf:type vCard:Agent
<node2> rdfs:label "SRDC"
...
08:37
suat
Yes, I see
08:37
westei
and if you get the Event data without the "cms" annotations ....
1. search for the URI in the CMS
assume found
2. get the mappings (Bridge) for the type of the object
3. annotate the incomming data with the according cms properties
4. send it to the callback RESTful service of the CMS
assume not found
2. get the Bridge for this type of RDF data (e.g. based on the type but
might be also other things)
3. the bridge should tell the parent node for creating this additional one
so users of the CMS Adapter would have two possibilities to use it
a) create bridges (configurations) that let the CMS Adapter now how to
deal with RDF data
b) send already annodated RDF to the CMS adapter
BTW there could also be an "mode" that tells the CMS adapter to
serialize the parsed RDF and store it as a document in the CMS
08:43
suat
I think you mean a set of nodes right?
08:44
westei
in respect to what?
08:44
suat
I mean after parsing RDF, hiearchies or seperate nodes can be created in
CMS according structure of RDF
08:45
westei
In the case of the Event Example as used above -> when parsing the whole
RDF data of the IKS Community Workshop in Paris a lot of nodes in the
CMS would be updated/created
08:46
suat
Ok I see
08:47
westei
I think the RDF Path Language could maybe useful to define such mappings
http://code.google.com/p/kiwi/wiki/RdfPathLanguage
08:48
suat
Yes, another point I wanted clarify was feature of these bridge
As far as I see you foresee that bridges would react according types of
nodes
08:48
westei
e.g.
participant = vCard:participant :: cms:Node
would say store values of the property vCard:participant as a child node
with the name "participant"
if we use the same path language also for the semantic indexing, this
could be really a cool thing
To answer "As far as I see you foresee that bridges would react
according types of nodes"
I would assume that the "rdf:type" property is very ofter used to match
Bridges, but I think to make bridges only to react on this would be an
over simplification
e.g.
Lets assume we have Events of IKS and APACHE
you might want to store IKS Events under a different parent node than
APACHE Events
With the RDF Path Language one could do that (see section about
Resource Path Value Tests)
09:05
suat
Then we will have a bridge interface which provides access to RDF Path
language expression specifying target RDF resources and a target path in
CMS representing location where nodes will be created
09:14
westei
I think it is the best to start with:
* defining the "cms" ontology
* basic mappings (as in the example above)
basically moving the current functionality over to RDF
next I would add
* bidirectional stuff with simple mappings
* using Bridges to store unannotated RDF in the CMS
* storing/update the CMS based on annotated RDF
this subset is much easier to implement and I think such a demo would
generate a lot of interest
only if this is working I would start with the more complex things (e.g.
by using the RDF Path language
Sebastian an I are on vacation until September and I think we will also
to start than to move LMF functionalities over to Stanbol
09:20
suat
Yes I read that thread
Now things are more clear in my mind. Thanks for the ideas
I had difficulties to estimate really useful requirements
09:21
westei
I see the CMS Adapter as an central component for that, because
currently the LMF is its own CMS, but than it will need a possibility to
store its data to a real CMS -> the CMS Adapter could be exactly this
interface/component
- - -
14:29
suat
I was preparing the mail but I think there are unclear parts in my mind.
First do you have that simple example about event and participant
14:29
westei
ok ... was just a reminder
no I typed it directly to the IRC
I can past it again If you need it
paste
14:30
suat
<node1> rdf:type cms:Node
<node1> cms:path "{path}"
<node1> rdf:type vCard:Event
<node1> rdfs:label "Community Workshop Paris"
<node1> vCard:participant <node2>
<node2> rdf:type cms:Node
<node2> cms:parent <node1>
<node2> cms:path "{path}"
<node2> rdf:type vCard:Agent
<node2> rdfs:label "SRDC"
it was like that
my question is:
will we assume that RDF will have cms related properties such as
cms:Node, cms:path etc?
14:31
westei
you mean the RDF as parsed to the CMS Adapter?
14:31
suat
yes
14:32
westei
users of the CMS Adapter would have two possibilities to use it
08:41
a) create bridges (configurations) that let the CMS Adapter now how to
deal with RDF data
08:41
b) send already annodated RDF to the CMS adapter
So basically I see both options, but option would be the more realistic one
14:33
suat
then bridges will be used to specify resources that will be created as
nodes in CMS
also to specify hierarchies between them
as you guess I mean the resources in the RDF
14:35
westei
I am imagine a Component (e.g. a Processor or maybe a bridge) that
processes the parsed RDF and adds the "cms:..." annotations based on
some configuration
than an other component that simple stores annotated RDF to the CMS
so we could use KRES functionality, the RDF Path Language or any other
component to process parsed RDF
at first we would use a simple implementation that maybe knows how to
store stuff based on the rdf:type
The other component - that stores the RDF to the CMS - would than be
only bordered about how to store annotated RDF to a specific CMS
Here I see the CMIS, JCR and RESTful Service based implementations
14:42
suat
For JCR it easy to create custom properties but as far as I see it is
not possible in CMIS
14:45
westei
than for CMIS one would need to store such things as "content"
(serialized RDF)?
14:47
suat
do you mean directly storing RDF itself?
14:47
westei
yes
Serializing all RDF data you can not represent directly in the CMS and
storing them as String or Document
I implemented something like that for http://fedora-commons.org/
14:49
suat
Yes, it can be stored as a document. Do you suggest it to relate some
RDF with actual documents in CMIS repository?
14:50
westei
no storing the RDF data as a document (or a property or subnode ... no
Idea about CMIS) within the CMIS Repository
the CMS Adapter would just need to know how to lookup the RDF data for a
Node
I know such RDF data would be a blackbox for the CMS, but at least they
would be managed by the CMS
so if Stanbol could be restored based on the data stored within the CMS
14:55
suat
14:55
Ok then. I shall complete the mail
--
Suat Gönül
Software Research, Development and Consultation Ltd.
ODTU Silikon Blok 1. Kat No:14
Middle East Technical University Campus
06531 Ankara TURKEY
Phone: +90 (312) 210 1763
Fax: +90 (312) 210 1837
