Well, after the little amichi vendor slamming, I am a little leary about
posting this, since it does indirectly support a product offered by my
company, but I think it is still useful information based on your question
about metadata. This is a short article I wrote talking about storing
metadata/
Hi Mattias
The other
method is using a dynamical database implemented in sql where you can define
different attributes for each document.
I haven't programmed in awhile, but I would be surprised if you
couldn't add this feature using XML also. Correct me if I am wrong -
and from the spunkines
From: "Vap, David" <[EMAIL PROTECTED]>
> It would be really nice if next generation CMS knew more about the actual
> content of the content and, that is exactly what is happening. Next
> Generation CMS vendors are storing content directly in a native XML store.
> The benefits of this are numerou
Mattias,
For the benefit of reviewing other approaches, you might want to look at
the solution produced by ww.dstc.com, they have a product called HotMeta.
Developing a Metadata solution that supports current and future metadata
schema's can become overly, and unnecessarily complex, and the HotMe
there are several issues to consider:
1, what you will use the metadata for, both in the short-term and in
the long-term. If you plan to have extensive personalization, for
example, you'll want to begin collecting lots of metadata.
2, you'll need two kinds of metadata --
* attributes of the co
>>>convert the incoming XML stream into a set of relational tables that
>>>meta-modeled XML structures. Anyone who has done this before knows,
XML
>>>to Relational Mapping can get quite complicated.
I have. The worst is the nesting and finding what nodes to update.
There almost has to be ground
Hi Mattias,
I second the comments from Donna, Hillary and Tony, but allow me add a
couple thoughts of my own. This is one of my favorite topics, so please
excuse the long post.
I would submit that neither SQL nor XML are really the best data model for
CMS metadata. If you are limited to the
I would submit that neither SQL nor XML are really the best data model
for CMS metadata. If you are limited to these two, I would go with XML
and rely on the capabilities of a decent XML database that allows you to
treat the XML interchangeably as either deep or shallow and provides a
decent q
> > I would submit that neither SQL nor XML are really the best data model
> > for CMS metadata. If you are limited to these two, I would go with XML
> > and rely on the capabilities of a decent XML database that allows you to
> > treat the XML interchangeably as either deep or shallow and provi
At 05:00 PM 2/6/2003 +0100, Mattias Konradsson wrote:
[Relational Method.]
This method would allow you to create a "dynamic database" inside of sql
server. Luckily I already developed this part for handling user prefences
when I realized that i couldnt fix them to a certain set of attributes bu
Jonathan Peterson wrote:
> I often hear that databases are 'bad' because a
> change to the taxonomy requires much work re-writing
> SQL queries, whilst in XML, a change merely requires
> updating a schema. I can't say agree. All data
> processing makes assumptions about the data.
Well, I suppose
Charley wrote:
>The ever-present "Databases V. XML: Battle To The
>Death" comes from the fact that (relational)
>databases are *highly* structured, and XML offers
>more degrees of freedom from *highly* to *partially* structured.
>From experience the degree of freedom that XML gives within the s
Nuno wrote:
> Hi Charley, very interesting indeed your little MV
> query engine, how have you implemented it? In other
> words what is the underlying data store?
>
> 1) Is it an RDBMS?
> 2) Is it a file or multiple files in the FS? If so
> what is the format of those files, XML?
Our data store is
Hi Nuno,
At 12:03 AM 2/8/2003 +, Nuno Lopes wrote:
Hi Charley, very interesting indeed your little MV query engine, how have
you implemented it? In other words what is the underlying data store?
Me and Charley Bay are two different people. I actually go by Charlie most
places. I decided
Charles Reitzel wrote:
> Hi Nuno,
>
> Nuno Lopes wrote:
> >Hi Charley,
>
> Me and Charley Bay are two different people. I
> actually go by Charlie most places. I decided to
> go by Charles on this list to avoid confusion with
> you, Charley! No biggie.
Ooops. Sorry to interject. ;-)
I'll
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
On Behalf Of Charley Bay
Sent: segunda-feira, 10 de Fevereiro de 2003 3:26
To: Charles Reitzel; Nuno Lopes
Cc: [EMAIL PROTECTED]; Charley Bay
Subject: RE: [cms-list] managing metadata
Charles Reitzel wrote:
> Hi N
Hi Charley,
Interject away. I read your post with great interest. And, please, you
all ;-> were here first, and lots of people call me Charles anyway. Nuno's
just used to talking to you.
The code I originally inherited (before I created the query engine) was a
grab bag of Perl scripts that
On Behalf Of Jonathan Peterson
Sent: Thursday, February 06, 2003 6:47 AM
To: [EMAIL PROTECTED]
Subject: Re: [cms-list] managing metadata
> I would submit that neither SQL nor XML are really the best data model
> for CMS metadata. If you are limited to these two, I would go with
XML
&
'Jonathan Peterson'; [EMAIL PROTECTED]
Subject: RE: [cms-list] managing metadata; Perfomance
>Would you store XML as BLOBs in a RDBMS? Pros/cons?
I've actually recently been starting to store XML files as BLOBS within
Oracle. This seems to work really well, except for the case
AIL PROTECTED]]
Sent: Thursday, February 06, 2003 8:00 AM
To: 'Jonathan Peterson'; [EMAIL PROTECTED]
Subject: RE: [cms-list] managing metadata; Perfomance
>Would you store XML as BLOBs in a RDBMS? Pros/cons?
I've actually recently been starting to store XML files as BLOBS within
Here's some of my experience:
> Tony Wrote:
> Would you store XML as BLOBs in a RDBMS? Pros/cons?
> Would you store XSLTs as BLOBs in a RDBMS? Pros/cons?
> I think XSLTS should be stored on disk...but XML data can be stored in
> many ways...Mapped, as BLOBS, etc.
I came to the overall conclusio
; 'Jonathan Peterson'; [EMAIL PROTECTED]
Subject: Re: [cms-list] managing metadata; Perfomance
Here's some of my experience:
> Tony Wrote:
> Would you store XML as BLOBs in a RDBMS? Pros/cons?
> Would you store XSLTs as BLOBs in a RDBMS? Pros/cons?
> I think XSLTS should
tonyl/pillarsoftware wrote:
How do you believe Metadata changes should be approached in the
following cases?
1) If the reason for the Metadata change is the introduction of a new
business rule that will require code changes.
2) If the reason for the Metadata change is simply to capture more da
> How do get people to add the metadata and when
If you ask me, this is at least as important (if not more so than) than
figuring out how to store the stuff. GIGO and all that.
One example: Our print production system is based on a page metaphor - there
are places to enter meta-data for each doc
> tonyl/pillarsoftware wrote:
> > 1) If the reason for the Metadata change is the introduction of a new
> > business rule that will require code changes.
> >
> > 2) If the reason for the Metadata change is simply to capture more data
> > that is non-essential to any transaction processing.
Can you
Hi all, this topic is of great interest for me too.
Me and a couple of friends we have been developing a brand new CMS
system using the .NET framework. We are using a relational database to
store and manage metadata. We had a couple of brainstorm around how to
store metadata effectively. We all ha
At 01:08 AM 2/7/2003 +, Nuno Lopes wrote:
Quite often multi values are used to define semantic categories
(World(Region(Continent(Country(Country(Region(City))). When querying
this is a simple conjuction:
Look for companies in:
[Region] AND [Continent] AND [Country] AND [Country Region]
Hi Charley, very interesting indeed your little MV query engine, how
have you implemented it? In other words what is the underlying data
store?
1) Is it an RDBMS?
2) Is it a file or multiple files in the FS? If so what is the format of
those files, XML?
In the case of 1) do you use the LIKE state
Thanks everyone for the input, interesting discussion for sure. I decided to
go with my dynamic database approach using entity and attributes. Storing
metadata simply in the database while clean and flexible solution simple
isn't viable since it in effect renders the metadata invisible from the
sta
29 matches
Mail list logo
