avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Niclas Hedhman <nic...@hedhman.org>
Subject [RT] The Avalon Block Round 2
Date Thu, 13 Nov 2003 10:33:20 GMT

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


Mime
View raw message