Anything about Tenor? & creating a content system -> RDF

Kévin Ottens ervin at ipsquad.net
Thu Aug 11 13:13:42 CEST 2005


Le Mercredi 10 Août 2005 16:44, Leo Sauermann a écrit :
> Something with more 20% more
> quality could mean 80% more programming and research effort.

Right.

> well, if you look at it closer, you can add metadata (and any triple) to
> a lucene document. they provide property/value pairs, which is a start.
> A real graph needs something else, but lucene is quite ok to add author,
> date, downloadedFrom, lastChange, thisAndThat to documents.

As you said, it's a start. ;-)

> -> I don't want to convince anybody here to use lucene, it does not
> fulfill all your needs.
> But if you can, rip the code apart and copy/paste as much as you can.

For the record there's already an ioslave playing with the C++ port of Lucene:
http://www.kde-apps.org/content/show.php?content=23874
http://kioclucene.objectis.net/documentation/demos/demo1

> ok, that is good to do. Drill down your requirements and your wishes to
> the system and then see why RDF doesn't work. e.g. the performance may
> be bad or the Meta-Description language (RDFS/OWL) too complicated, ....

Ah-ah RDFS/OWL detected. =)
Yes that's exactly my biggest worry with RDF, it could quickly become overkill 
we surely don't want to support most of its vocabularies.

> no, as RDF is the most generic data format there is. point. You can
> express anything in RDF. All relationships.  Any other language will be
> either restrictive (meaning that it supports less relationships or only
> relationships X and Y) or it will be isomorphic to RDF (meaning that you
> reimplemented RDF)

You state the obvious, the point is more do we really want and need to express 
anything?

> there are some points in RDF that suck, like sequences or lists, but
> these can be handled.

Could you be more precise here?

> >In this case, I'd like to be able to have a textual format in order to
> > have a clearer opinion about RDF usage in Aduna Autofocus. I can't find
> > such an export unfortunately.
>
> ok, I'll bug the developers for this one.

Thanks a lot.

> sure, but you will need a metadata format anyhow.
> The big ontology work is not sitting down and writing an OWL file, the
> problem is to agree with people like the nifty guys in this email-group
> if we now call the thing "title" or "name" or "label". That is really
> the hard work.

Oh please, don't get me on this... your view is only about one flavor of 
ontologies. In the general case you know that it really raises more questions 
on a structural level and the ontology refinement is a work by itself. In 
particular when you're working on domain ontologies where it's difficult to 
reach a consensus on the domain representation it's not only about naming 
some properties but which concepts you'll keep in the final version. You have 
also to be sure that it meets the requirements for the resulting application.

> So usually I take an existing ontology (like MP3 id3 tags) and convert
> it to something like this:
> https://gnowsis.opendfki.de/cgi-bin/trac.cgi/file/trunk/gnowsis/src/org/gno
>wsis/adapters/MP3/ontology.rdfs
>
> the discussion work has already been done, you just sit down and rewrite
> it to a new document (which wasn't there for MP3 - there was only a HTML
> page with some text. A formal description is nicer)

I guess that for data formats "ontologies" are really easier to obtain, since 
the available metadata were fixed first anyway. Nice point, I didn't noticed 
it earlier, it's maybe because I have to deal with domain ontologies on a 
daily basis.

> So, what would be the gain for using C++ in Tenor if we don't use
> Factories/lateBinding/libraries/freakyC++directivesthatwereneverused.
> Its just a programming language and C does also the trick. Nothing
> guarantees that C++ is the best solution in our case.

Yes, but we have guarantees that it's a better solution than C in our case. Do 
we have guarantees that going for RDF formalism is better than an ad hoc 
model in our case? not sure...

> Yes, but the world at a whole is moving towards RDF and you don't need
> ontologies, you just need the graph representation and good
> import/export to RDF. You need the ideas and the commmunity of
> researchers, hackers and projects.

You should really avoid using such absolute terms. A particular community as a 
whole is moving towards RDF, it's not just because you are in this particular 
community that the world as a whole is moving towards RDF.

> there may be a moment in time, when you look at your product, tenor, and
> say:
>
> gee, I whish we had used C++ that day in 2005, then we would have
> namespaces now and C lames.
>
> gee, I whish we had used RDF that day in 2005, then we would have  ....
>
> * the freaky GUI from http://www.mindswap.org/
> * the cool metadata (kissing and beer drinking) from
> http://www.schemaweb.info
> * that lovely worldwide RDF search engine on http://swoogle.umbc.edu/
> * that lovely worldwide RDF search engine on
> http://www.semanticwebsearch.com/

Which avoid most of the web content since you can read papers complaining that 
even people working in the semantic web field are not able to tag correctly 
their documents.

> * that metadata extractors/file filters from aduna, gnowsis, kowari,
> intellidimension,  ...

I admit that at least Aduna looks interesting in this matter. As for gnowsis, 
it's on my todo on things I should test, but I doubt I'll find much time to 
do it for a while.

> * that nice community of developers where i can sleep for free in all
> major towns

Hehe, I know another one in this regard : the KDE community.

> .. now and the triple framework we built from scratch lames.

Oh, come on, it's not because it doesn't use RDF that it'll be lame. ;-)

> jup, that i did now. You note that little owl thing above. don't use
> OWL, just use RDF.

I knew you'll end up citing it. =)
But well, that's no problem for me, I just expected some people to cry loudly 
if you speak about OWL, but it seems I was wrong.

Regards.
-- 
Kévin 'ervin' Ottens, http://ervin.ipsquad.net
"Ni le maître sans disciple, Ni le disciple sans maître,
Ne font reculer l'ignorance."
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://mail.kde.org/pipermail/klink/attachments/20050811/0ddf5fb0/attachment.pgp


More information about the Klink mailing list