Yes, that's very much along the lines of my thinking, as is Carl's mention
of keywords.
A good place to start would perhaps be
http://www.dublincore.org and
http://www.dublincore.org/documents/1999/07/02/dces/
Another crack at it:
REBOL [
File: %index.r
Description: "Rebsite index with MetaData in block header"
Author: [EMAIL PROTECTED]
Date: 2002-09-08
Metadata: [
%rebsites.net/dublincoreengine.r [
title "some title"
creator "K. Watson"
subject "Rebsite, indexing"
description "Rebsite index with MetaData in block header"
publisher "K. Watson & Friends Inc."
contributor "J. Smith"
contributor "Hay Uthere"
date/created 2002-09-04
date/modified 2002-09-08
type "Software"
identifier http://wherethislives.com
language "en-US"
rights "K. Watson & Friends Inc."
]
%anotherrebsite.org/generickeyvalueengine.r [
'somekey 5
'someotherkey "a text value"
'anotherkey [ block values ]
'andonemore 'key
]
]
]
-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of
Jason Cunliffe
Sent: September 8, 2002 10:15 PM
To: [EMAIL PROTECTED]
Subject: [REBOL] Re: informal /View desktop survey
> Certainly that's a starting point; however, the Rebol header block is
> extensible, not mandatory, and not really typed in any way. My first
thought
> is a func in a well-known .r file that mandates certain metadata that
would
> be understood by the engine, and that would send it to the engine and
> publish it.
>
> K.
Hi Kemp,
Do you mean something like :
REBOL [
File: %index.r
Description: "Rebsite index with MetaData in block header"
Author: [EMAIL PROTECTED]
Date: 2002-09-08
Metadata: [--keywords and sub-blocks here--]
Engine: %rebsites.net/engine.r
]
...Where the engine.r would be a sort of rebolistic version if XML-DTD but a
lot
nicer :-)
And the Metadata: block in the header would be picked up by any interested
service.
The remote service would have the choice to use its own engine and/or load
or
compare against the one defined in the script header block. Something to
allow
easy convergence or divergence as application or access demands.
Then at a minimum engine.r might check for a basic metadata block. A small
script or View/app could be run to invoke the engine check that files and
help
people to quickly accurately add/edit their metadata fields without having
to
remember detailed syntax or get too low down..
The engine.r loaded in the desktop app might also check for obvious
conflicts
between a local engine and a remote one... [which could lead us to the hairy
topic of topic maps]
The key point being a reasonable separation of content and tool, but
exploiting
REBOL lovely way of fusing them ;-)
hope I am making sense here..
./Jason
--
To unsubscribe from this list, please send an email to
[EMAIL PROTECTED] with "unsubscribe" in the
subject, without the quotes.
--
To unsubscribe from this list, please send an email to
[EMAIL PROTECTED] with "unsubscribe" in the
subject, without the quotes.
