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]
