Xesam meta-meta-data spec needs attention.

[Evgeny Egorochkin]

On Friday 04 May 2007 14:31:21 jamie wrote:
> On Fri, 2007-05-04 at 14:00 +0300, Evgeny Egorochkin wrote:
> > Missing are structures. As soon as we go further than generic metadata
> > like author and size, and try to extract document structure, we'll run
> > into troubles. An example: c++ sources with nested classes and their
> > members. Too many workarounds would be necessary for .desktop
>
> this is doable (we do support this in tracker and plan on adding support
> to desktop files for this)
>
> You would have a metadata type of struct
> and have another field "children" that lists the child metadata names
>
> Each child metadata will have its own def
>
> Eg  for a struct type for Email:Address containg Contact:Name and
> Contact:Email you would have:
>
>
> [Contact:Name]
> DisplayName=Contact:Name
> Type=string
>
> [Contact:Email]
> DisplayName=Contact:Email
> Type=string
>
> [Email:Address]
> DisplayName=Email:Address
> Type=struct
> Children=Contact:Name;Contact:Email;

This apparently solves the storage issue for this particular case. However, 
there are several shortcomings:
1) Structures are not extensible.
	*You cannot define generic structure for an OO language and subclass it if 
necessary.
	*Applications can't add custom fields to existing structures.
2) Data retrieval. 
If you put the whole structure in a single property, you make it hard e.g. to 
use several  files to describe a single structure. Also, it is hard to 
interlink classes e.g. point to ancestor class(es).
If you make all structure nodes e.g. c++ classes high-level nodes just like 
files, you get an issue with node classes which cannot be resolved by 
introducing node type property due to lack of inheritance.

and the reason we experience these thoubles is...

3) This approach departs from RDF in the sense that RDF is 
property-centric(not class defines its properties, but properties define 
their class) and omits class type information which is quite essential.
This quite expectably backfires.

As you can see, implementing e.g. a generic source code browser is 
problemmatic with this approach.

I believe there are many usage scenarios with similar issues.

Let me sum this up.

*** Pro-RDF arguments:
1) If we declare to have RDF compatibility in mind, we cannot really go too
far away. We might change syntax, we might omit features. As we develop the 
standard along the RDF compatibility line, we will end up with another RDF 
serialization format. No more and no less.

Adding something on top of RDF is not an issue so far since we're discussing 
limiting it instead.

Departing from RDF line should at least be motivated. What RDF+named graphs 
lack and *how it can be implemented better*.

2) RDF is powerful and flexible. It can be both simple from the start and 
powerful if you need it.

3) RDF is a standard and as such has much better support in terms of tools and 
*interoperability with other software*.

*** Contra-RDF:
1) .desktop has cleaner syntax.

This is an example of an actual RDF serialization + named graphs 
extensions(which does support localization as suggested by Sebastian)

@Prefix ......................  // 1-2 lines copied intact for all files
@Base ......................

Mp3.Title
	is_a			field;
	of_type		string;
	name		"Title"@EN;		// not sure I got intl syntax right from the get go
	name		"Titel"@NL;		// but likely so
	description	"Mp3 title"
	...
	comment		"example".

Mp3.artist
	is_a			field;
	of_type		string;
	has_parent	Content.Creator
	name		"Artist";
	description	"Mp3 artist";
	...
	comment		"example".

Anything I've missed?

-- Evgeny