robert burrell donkin wrote:
On 12/20/06, Steve Loughran <[EMAIL PROTECTED]> wrote:
robert burrell donkin wrote:
> On 12/19/06, Steve Loughran <[EMAIL PROTECTED]> wrote:
>> robert burrell donkin wrote:
>> > On 12/19/06, Steve Loughran <[EMAIL PROTECTED]> wrote:
<snip>
>> 2. looking to get management approval to hand the code to the MIT
Simile
>> project (e.g. Stefano)
>
> cool
>
> (there seems to a lot of interest developing around RDF ATM amongst
> apache members)
>
> stefano's keen to see discussions related to apache and RDFs in the
> labs
>
http://mail-archives.apache.org/mod_mbox/labs-labs/200612.mbox/[EMAIL PROTECTED]
>
> (which makes sense to me.)
In theory, RDF is a "better" way of gluing together metadata in a way
that is tool neutral. For little tools, it should be effective.
I know Stefano is a fan of the semantic web, but to me the JAR
repository is an interesting analysis of how well it will work. We know
that today there's a lot of inconsistency out there, even though there
are some dedicated people (esp. Carlos) who put a lot of effort in to
keeping things under control. If we have problems chaining together
metadata from a single repository, what are the long term implications
for the semantic web going to be?
+1
be interesting to see the level of practical benefit from application
neutral meta-data
yes indeed.
>> 3. Thinking of something to audit the metadata. Maybe in prolog (my
>> choice), maybe something else.
>
> i plan to persuade projects (by including this in RAT rather than a
> conventional configuration file) to start recording auditing meta data
> about documents which didn't originate at apache in RDF. i've also
> been toying with the idea of using RDF to record relationships between
> licenses and policy about licenses.
>
> these sound like related problems to me
yes, one of my proposed 'enhancements' for both pom and ivy.xml files is
to include an audit trail in there, such as who created the pom.
Supporting a metadata element that took RDF-as-XML triples would be a
very extensible way to do this. Wagon and Ivy could ignore the data, but
other tools could extract it.
+1
probably want more than just creator. for a repository, the creator of
the pom may be different from the distributor who uploaded the
descriptor and the original author of the artifact described. all of
these would be useful in determining the audit trail. for example, i'd
be more inclined to trust an artifact with signatures from
representatives of each group than any alone.
you're into a pool of complexity there. Ideally, each artifact should
have an extensible set of metadata, including stuff that could be added
later, even by different people. Instead of having RDF triples, each
"fact" should be marked as who issued it, and when. We'd require that
each entity/agent is consistent at a point in time, but they are allowed
to change their mind later, and other people are allowed to be utterly
inconsistent.
the hard part is reconciling all that data, as you cannot just treat
them as facts to chain off. you need to look at later stuff first, and
apply trust rules to the entities. Which is why the current set of RDF
tools don't go there yet.
How would you use RDF to differentiate the mysql interpreation of GPL
from everyone elses?
i've been trying to work that out for a while
it seems to me that there are several different layers of meta-data
for a particular resource (an element of an open source project), i'm
interested in license, license family, origin (url where the copy came
from) and rights holder. (maybe other stuff such as whether it's been
modified)
i'm also interested in questions about aggregates: whether a
particular collection of elements can be distributed together given
some rules and meta-data about the other URLs referenced in the
resource meta-data. together, these rules and meta-data would be
policy.
in the case of mysql, the family would be GPL but the license would be
mysql-GPL. a policy might decide to trust their promise and describe
this in meta-data. (i haven't really had time to explore this yet but
i have hopes that this combination might be enough to make things
work.)
I see, so the relaxed LGPL policy would declare that they consider
themselves compatible with ASF2, and apache could consider themselves
compatible with GPL, but the FSF could say that they dont (or that they
havent decided, which is a separate fact)
[error] artifact rejected.
[error] It happens sometimes. People just explode. Natural causes.
+1
humour injection is a powerful design pattern
repo man powers the satirical web
Maybe we need a commons-imdb-quotes package that retrieves quote bundles
from IMDB for reporting. When you install an app you can choose whether
you want quotes fro repo-man, life of brian or even the al pacino
version of scarface.
-steve
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
