[RT] The Avalon Block Round 2

[Niclas Hedhman <ni...@hedhman.org>]

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

Re: [RT] The Avalon Block Round 2

[Niclas Hedhman <ni...@hedhman.org>]

On Thursday 13 November 2003 19:01, Steven Harris wrote:

> 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.

My main argument is that there are, or should be, off-the-shelf storage, 
creation, indexing and search solutions for RDF, but we are doomed to roll 
our own, that is an Apache TLP by itself.

Niclas

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

Re: [RT] The Avalon Block Round 2

[Steven Harris <st...@kenamea.com>]

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

Re: [RT] The Avalon Block Round 2

[Leo Simons <le...@apache.org>]

Niclas Hedhman wrote:
<snip/>
> IMHO, RDF provides us with exactly the resource description we need.

+1!

However, be weary of making RDF too complex. It is quite easy to make 
things too flexible using RDF. Also, I strongly believe in the LCD of 
the basic filesystem. After all, it has worked so far for every 
packaging mechanism in existence today.

I bet that if you keep LCD-compatibility in your RDF sublanguage, it 
will remain simple enough.

- LSD



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