avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Steven Harris <st...@kenamea.com>
Subject Re: [RT] The Avalon Block Round 2
Date Thu, 13 Nov 2003 11:01:02 GMT
I'm sure your right about RDF's applicability here. I am, however, a 
bit concerned
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: dev-unsubscribe@avalon.apache.org
> For additional commands, e-mail: dev-help@avalon.apache.org
>


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org


Mime
View raw message