Re: [office-metadata] Our discussion on the Wiki example

[Bruce D'Arcus <bdarcus@gmail.com>]

On Dec 2, 2006, at 9:19 AM, Svante Schubert wrote:

>>  But how is that it's "mnemonic" intrinsically valuable? I don't 
>> think it is.
>
>  As well, easier to edit by human. You would recognize easier 
> copy&paste errors, for instance when there is a different URI in 
> meta:about and in the manifest, like even you did in the example. ;-)

That's not an error. The URI on the manifest entry is to identify the 
graph (the RDF/XML file). The URI on the citation identifies the 
citation resource.

I think this (what the id looks like) is a distraction. Let's just 
focus on local and global URIs (your's is local). And I really think we 
need to accept Elias' argument that we need to treat these ids as 
opaque. They are for machine-resolution, and nothing more. That doesn't 
mean you can't make them look nice of course: 
http://ex.net/colors/blue.

>>> By this it is imaginable that even the implementation of metadata is 
>>> being exchanged in meta.xml, without a byte changing in the 
>>> content.xml. Imagine implementations like vcard vs. hcard.
>>
>>  Am not following here. Can you restate?
>
>  There are always different ways to state the same semantic, like 
> informations about persons using vcard or hcard.

hcard is HTML. So there's no hcard here.

The way it might come in is a transformation to an RDF/XML 
representation of it. So user copy-and-pastes hcard-enhanced content 
from a web page, and it gets transformed upon pasting into an ODF 
application.

But that doesn't effect our system.

>  And certainly there are descriptions how to transform grammar into 
> the other.
>  This might be transformed in the metadata folder without touching the 
> content.xml.

Ah, OK, right, but I don't see how this is anything but an 
implementation detail. If you need a config file to do something, add 
it. The metadata system would be agnostic about what you use it for.

>>> Second someone would like to link to meta data.
>>
>>  I still don't know what this means.
>  If I want to link to these employees, I don't want to define the 
> document structure(s), where they are embedded, but simply want to 
> link to the semantic of 'employee'.

Let's parse the language here.

What we've been talking about in using things like the meta:about 
attribute is a way to identify content, and in doing so to enhance it 
with further description. It's not exactly linking.

In the RDF model, then, you are defining that document object as a 
resource.

Remember, the RDF model has resources and properties.

But RDFa also allows you to tag content as a property. I think that's 
what you're getting at here. E.g.:

	<text:span meta:property="http://ex.net/employee";>Jane Doe</text:span>

... or (correct me if I'm wrong Elias!):

	<text:link
		meta:href="http://ex.net/employees/1";
		meta:rel="http://ex.net/employee";>Jane Doe</text:link>

In N3, the first would be:

	ex:employee "Jane Doe" .

... and the second:

	ex:eployee <http://ex.net/employees/1> .

[...]

>>  No, Svante. That's certainly not how you'd do it in RDFa. The ID is 
>> just that: an id that allows one to then associate something else 
>> with it (a link, metadata descriptions, etc.). It indicates no 
>> semantics at all. Using dumb strings of text for semantics is no more 
>> useful than just using styles.
>
>  There is no rule that the id's should express any semantic, but it 
> can help a lot when the XML is reviewed by a human and that is one 
> advantage of XML.

My point is to go back to the model and to the RDFa: there are 
names/ids (about), properties (property), relations (rel), etc. They 
are not the same thing, but the way you were presenting the examples 
seemed like you were saying they were.

[...]

>>  OK, I think you need to step back and ask what problem are you 
>> trying to solve here? It seems to me you want to be able to bind a 
>> GUI to data, and then to particular application behavior (which could 
>> be a plug-in). E.g. say someone wants to add custom content 
>> processing; how do you do that? How does a plug-in know which content 
>> and which metadata to deal with?
>>
>
>  Different vendors implement different plug-ins for different 
> meta-data. Like various vendors for citation.
>  Aside of this, there should be one default installed plug-in, which 
> take care of meta data if there is no certain plug-in installed.
>  All these questions for the big picture: how to get the correct 
> plug-in - questioned by the ODF application - or is there already a 
> grammar (and plug-in) for my semantic - questioned by an ODF editor -, 
> are not asked, yet. These application problems might need some help 
> from the ODF as well.

OK, I see. Why can't we just do:

  <manifest:file-entry
      manifest:media-type="application/rdf+xml"
      manifest:id="urn:uuid:fe107eb0-7704-11db-9fe1-0800200c9a68"
	manifest:type="http://opendocument.xml.org/bibliographic";
      manifest:full-path="bibliographic/meta.xml"/>

In order, the attributes say:

	- this is an rdf/xml metadata file (a graph)
	- this is its name (a global IRI; I wonder if this should be local 
though?)
	- this is its type (for a plug-in to register responsibility, say)
	- here's its location

>  OK, remember, what you are calling an "embedded grammar" is exactly 
> what RDFa provides.
>
>>  I see RDFa as a very good opportunity to learn from, but as HTML has 
>> one plain document and we are a compound package we have certain 
>> advantages we should use.

Granted, but the way you're approaching it above is to throw it out 
altogether without explanation. I suggest we work the other way around: 
assume we use all of RDFa, and throw out what seems inappropriate (like 
maybe the content attribute: I don't know).

Perhaps a way forward is to just continue to expand the examples I 
started based on our use cases. I need other people to do that, as I 
just don't have a lot of time these days.

I'm pretty sure what Elias and I are proposing will work for pretty 
much anything, so let's see if I'm right and adjust as needed?

Bruce