Fwd: Re: [Clipart] metadata: aren't the keywords actually categories (and can keywords be added)?

[Mike Traum]

Jonadab,
The big xml file could also be exploded by any tool that could read
xml, but that's moot because I misunderstood the implications of a
hard link.

Further along in this thread you'll see that I was totally mistaken
about how a hard link was represented on ext2, ext3, and probably
most other unix based filesystems (ie, it's just an inode reference,
and not a copy of the file). This also works in tar.

So, I think that using hardlinks is quite an appropriate solution,
assumming that the release manager is builing the packages on a
unix/linux system which supports them. You get the benefit of having
a smaller download and users who are using firesystems which support
them get the benefit of saving storage space. The only issue is users
who are using filesystems which don't support them (Windows, FAT32
and NTFS i believe) will end up using more of their local store, but
that seems acceptable to me.

Regarding the 'best of' packages, those are a good idea. I think
another great idea would be a shopping cart-type app. See Microsoft's
website, which I consider to be quite well done (and don't get me
wrong, I no MS advocate - I work exclusively on Linux):
http://office.microsoft.com/clipart

mike

--- Jonadab the Unsightly One <jonadab at bright.net> wrote:

> Mike Traum <mtraum at yahoo.com> writes:
> 
> > Andrew,
> > I understand the issues you raise with the big xml file proposal.
> > But, I don't think symbolic links will work, 
> 
> We have been avoiding symbolic links, because they are not very
> portable.
> 
> > and I do think that hard links is a very messy solution to the
> > problem. It doesn't scale well - what happens if openclipart has
> > 50,000 images? So many duplications in the package will just end
> up
> > in bloat.
> 
> I guess you weren't here yet when we discussed quality feedback
> mechanisms and subset distributions.  Long term, we want to have a
> web
> interface to receive quality feedback from the community at large,
> so
> that smaller collections can be produced containing the "best"
> (i.e.,
> highest-rated) n% of each category.  That however requires the DMS
> to
> be in place, among other things, and is realistically probably at
> least a year down the road at this point.
> 
> > How about a flat file structure with no path whatsoever? I think
> > this would make the most sense.
> 
> That was used very early on, but it scales even worse.  With some
> types of filesystems, performance goes straight to the toilet if a
> single directory contains more than a few thousand files, and if
> directories with thousands of files is bad for computers, it's much
> worse for humans -- nobody wants to look through fifteen thousand
> images in a directory every time they want to find one.  From that
> standpoint, the categories are a huge usability enhancement.
> 
> > Regarding the application I'm proposing, sure, I'll be able to
> > support pretty much anything. But, this all seems to be up in the
> > air right now, and I'd like to see some data definitions of
> proposed
> > xml files and a roadmap on the package structure before I start a
> > project based on all of that.
> 
> Here's a thought:  What if the big XML file that you want, that
> would
> only be useful with the specialized Java-based tool, was something
> that was distributed together *with* the specialized Java-based
> tool,
> as a part of *that* project, rather than being the primary OCAL
> distribution form.  That is, whoever creates the Java-based
> organizational thingy could also create the spec for the XML file
> that
> it uses, and code that generates it, either from one of our
> packages,
> or possibly by checking out from the DMS once that is in place.
> Actually, the latter seems like the better approach in the long
> run.
> Anyway, then you distribute the clipart organizer and the XML file
> that it uses together, as a package.  Would that work?
> 
> -- 
> $;=sub{$/};@;=map{my($a,$b)=($_,$;);$;=sub{$a.$b->()}}
> split//,"ten.thgirb\@badanoj$/ --";$\=$ ;-> ();print$/
> 
> _______________________________________________
> clipart mailing list
> clipart at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/clipart
> 



		
__________________________________ 
Do you Yahoo!? 
Yahoo! Mail - Find what you need with new enhanced search. 
http://info.mail.yahoo.com/mail_250