about how complex RDF can get (That same concern is why the world has three standard
versions of RSS ;-). Do we need this level of generality? Maybe yes maybe no.
Are most people more in the camp of having an ultra flexible repository that is self describing or do most people prefer something a little more rigid and defined yet potentially less flexible. Sort of a philosophical question. But for a repository I might lean towards in flavor of simplicity a little more than I would for the container itself.
On Nov 13, 2003, at 2:33 AM, Niclas Hedhman wrote:
Hi,
By taking the RDF approach to repositories, directories and indexing, we don't
need the specification for the repository, its protocol, format or
organization. That is not relevant. Which makes a lot of sense. We don't care
how we get the metadata, only about the metadata itself.
Furthermore, if the client (whether GUI tool or Merlin itself) can retrieve
all metadata via the same mechanism, i.e. the block.xmls are redundant, we
will have a nice unification between tools and container implementations.
By utilizing subclassing metadata, we can possibly easier support
semi-compatible and non-compatible blocks within the same specification.
I have previously brought up a few items. In this new light, let's look at
them again.
Naming & Identification
=======================
that Identification is not present in today's Avalon Blocks. They are only
identified in the local context, which is not enough. The use of URI
references are more than adequate and fits well into the RDF model.
Versioning
==========
As simple as a Predicate for each versioning style, and a meta data value.
Dependencies
============
Dependencies are declared using global Identifiers and Versioning. There is an
issue if we have a "depends on" predicate that points to an older resource
than "latest", RDF per se doesn't know how to resolve that. Let's see
below...
LifeStyle & Container/Environment Requirements ============================================== Declarations in suitable meta data.
Third-Party Requirements ======================== Right now I can't see what I meant on the 1st November :o)
JavaDoc and other documentation
===============================
By introducing an "Associate" descriptor concept, we can associate not only
documentation, but also "add-ons" such as user and programmable interfaces.
Internationalization & Localization =================================== I assume this would/could also be handled through "Associates".
Management Interfaces ===================== Not an issue in this context (I think).
So, getting to the grits.
1. We need to specify a SEMANTIC PREDICATES URI Reference, to which all
"predicates" belongs. For instance; http://avalon.apache.org/rdf/predicates
2. We need to specify a SEMANTIC OBJECT URI Reference, to which all "types"
belong. For instance; http://avalon.apache.org/rdf/types
I also suggest that we specify our model from scratch first, and see if we
overlap in some areas with other communities and whether we should adopt
their schema.
We need to start a PREDICATE list, which is the "relationships" between subjects and objects.
We need to start a TYPES list, which are the objects in our vocabulary.
My initial thoughts about predicates
====================================
The list below are predicates that pops out of my head right now. The names
are not important at this point. The respective types are inside < >.
I hope my syntax is user friendly :o)
<block> subclass of <versioned-resource> <block> depends on <versioned-resource> <block> consists of <versioned-resource> <block> has signature <literals> (? needed) <block> has license <license>
<community> has a homepage at <resource> <community> has a mailinglist <resource> <community> is named <I18N> (? or literals) <community> has a description <I18N> <community> consist of member <person>
<person> has a nickname <literals> <person> has a fullname <literals> <person> has an email <literals> <person> lives <location>
<versioned-resource> subclass of <resource> <versioned-resource> is named <I18N> <versioned-resource> has description <I18N> <versioned-resource> is of version <version> <versioned-resource> is created by <person> <versioned-resource> is owned by <community> <versioned-resource> has newer <versioned-resource>
<resource> has a URI Reference <literals>
<I18N> is in language <iso lang abbrevs> <I18N> has the value <literals>
<license> subclass of <versioned-resource>
<location> is in a town named <literals> <location> is in a state named <literals> <location> is in a country <iso country codes>
I am sure this will grow, but it is a start for discussion.
Conclusion; ===========
IMHO, RDF provides us with exactly the resource description we need.
My concern in "dependencies" could be solved within the RDF by linking the
"deprecated" version of the resource to one or more newer one(s).
The construction of RDF is dropped from the scope of this debate. We can have
a separate debate over that.
The indexing of RDF is dropped from the debate. It should be part of Google or
something.
The client retrieval of RDF is part of our problem domain, but I suggest we
leave it for a while.
Any comments?
Niclas
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
