cancel
Showing results for 
Search instead for 
Did you mean: 

Puzzling question on Predefined Properties

Former Member
0 Kudos

We all know the Global Metadata service in KMC. It allows us to define additional metadata properties for a configurable namespace within KMC (can be activated for specific repositories, folders, documents). We can use the flexible user interface to display the properties and to maintain their values.

It appears however that not all repository managers (connectors) support the use of it. If you look at the standard Repository Managers in KMC, you will see that that the File System Repository Manager does NOT support the use of predefined properties.

Common sense tells me that this could be explained by the fact that the file system repository manager does not have a store to save the extra metadata. It is implemented a file system client, to read and write documents and to retrieve basic resource properties.

The same however holds true for the WEBDAV repository manager. Yet this one does seem to support the use of predefined properties.

So the question is :

What makes the WEBDAV repository manager support predefined properties and the file system repository manger not, cause both do not manage a local store for maintaining that information. Does the WEBDAV repository manager use an internal KMC repository to maintain that metadata ?

In addition :

In a scenario where you are building your own repository manager for a specific data source, what are the special requirements in its design and implementation in order for it to support predefined property values ? What if your remote data source is read-only, can you still build a repository manager for it that does support the maintenance of predefined properties ?

Accepted Solutions (0)

Answers (1)

Answers (1)

Former Member
0 Kudos

1) The WebDAV repository manager stores custom properties remotely as WebDAV properties (that's one of the things for which WebDAV has been invented, after all...).

2) If you write a RM for a read-only data soure, your choice is either not to support write operations, or to persist properties somewhere locally.

Hope this helps,

Julian

Former Member
0 Kudos

Julian,

I will have to correct my initial posting (and your response 1), because after some further testing, it appears, that although the flexible user interface does show me the predefined properties in the details screen, for the resources residing in my WEBDAV repository, saving their values is NOT supported. When saving you will get a warning message telling you that the predefined properties "cannot be saved in this repository".

In the case of a WEBDAV repository, the available functions may depend on the capabilities of the remote WEBDAV server (in my case Microsoft's implementation on IIS), but this limitation seems to confirm my assumption in the initial post. BTW : I consider WEBDAV first of all as a simple extension of the HTTP protocol to enable writing and versioning. It does support properties, but it will depend on the implementation whether or not additional metadata can be managed.

The conclusion can only be that Management of predefined property values in KMC is the sole responsibility of each individual repository manager. There is no global infrastructure for this in KMC to maintain that metadata in a central store.

So, this means, you can only maintain additional metadata for those resources residing in those repositories in your KM hierarchy that are connected through a connector (RM) which supports their management.

So this excludes all read-only RMs as well as all external repository managers (file system, webdav, ...) that don't implement persistence machanisms for properties other than the default, standard resource properties.

So, the question remains : what are your options if

1. You need to maintain globally defined metadata for all your KMC repositories, irrespective the capabilities of the individual connectors involved.

2. the data source you want to integrate through a custom RM is read-only, but your scenario still requires you to maintain predefined custom metadata for the contained resources ? You are suggesting to "store them somewhere locally". What exactly do you mean by that ? Create a separate database schema that meets the needs for storing these properties, implement your RM to connect to both the remote data source and enable it to write properties to the extra tables made available ? This may be feasible, but it does create a huge synchronization problem between the metadata in KM and the ongoing changes in remote repository.

Former Member
0 Kudos

> Julian,

>

> I will have to correct my initial posting (and your

> response 1), because after some further testing, it

> t appears, that although the flexible user interface

> does show me the predefined properties in the details

> screen, for the resources residing in my WEBDAV

> repository, saving their values is NOT supported.

> When saving you will get a warning message telling

> you that the predefined properties "cannot be saved

> in this repository".

>

> In the case of a WEBDAV repository, the available

> functions may depend on the capabilities of the

> remote WEBDAV server (in my case Microsoft's

> implementation on IIS), but this limitation seems to

> confirm my assumption in the initial post. BTW : I

> consider WEBDAV first of all as a simple extension of

> the HTTP protocol to enable writing and versioning.

> It does support properties, but it will depend on the

> implementation whether or not additional metadata can

> be managed.

That's true, although a stricly conformant WebDAV server MUST support arbitrary properties. IIS should do that, except for the known issue it doesn't support the displayname property properly.

> The conclusion can only be that Management of

> predefined property values in KMC is the sole

> responsibility of each individual repository manager.

> There is no global infrastructure for this in KMC to

> maintain that metadata in a central store.

Yes.

> So, this means, you can only maintain additional

> metadata for those resources residing in those

> repositories in your KM hierarchy that are connected

> through a connector (RM) which supports their

> management.

Yes.

> So this excludes all read-only RMs as well as all

> external repository managers (file system, webdav,

> ...) that don't implement persistence machanisms for

> properties other than the default, standard resource

> properties.

>

> So, the question remains : what are your options if

> 1. You need to maintain globally defined metadata for

> all your KMC repositories, irrespective the

> capabilities of the individual connectors involved.

> ...

For instance, the Application Property Service.

Best regards, Julian