[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Semantics of objects in UDD : seeking more standardization, interoperability ?



Le dimanche 15 février 2009 à 16:19 +0100, Stefano Zacchiroli a écrit :
SNIP
> ... nothing forbids you to develop a semantics for UDD (in
> whatever language you want, web-ontologies being just one of the
> possibilities) externally to it. Actually, I'm also personally
> interested in doing that, even though I insist that it is not
> something that should be added *inside* UDD.
> 

Cool ;)

> > I have written a short piece on the subject
> > (http://www-public.it-sudparis.eu/~berger_o/weblog/2009/02/10/udd-swim-flossmetrics-facts-databases-about-libre-software-distributions-going-semantic/)
> > after the FOSDEM, and I'd like to get your comments on these ideas.
> 
> Sorry but I don't have the article with me, but I will reply as soon
> as I've a chance to read it.

Btw, In the meantime, we've been drafting a short paper following such
ideas, that we're submitting to a workshop at the next OSS 2009
conference... might pass a copy to interested folks, while waiting for
peer reviewing.
Note also the new MEPHISTO project :
http://www-public.it-sudparis.eu/~berger_o/weblog/2009/02/18/introducing-mephisto-aka-swim-before/ and http://code.google.com/p/mephisto/, launched by our Mandriva friends.

SNIP

> Now, back to how do that, I believe the main problem you will face is
> how to identify the objects in UDD, given that they potentially change
> daily and they don't have URIs identifying them. I see various
> possibility to achieve that, the first one is for you to develop some
> URI scheme which internalizes the keys used inside UDD.
> 

>From what I understood of Lucas' presentation, there are no internal
identifiers, nor so many relationships enforced in the DB at the moment,
(foreign keys, etc.) and mostly only string attributes (since there are
inconsistencies that UDD won't try to resolve, among other reasons).
Thus, the URIs can be quite easily constructed from those strings.

I'll probably start by looking at bugs (since this is the goal of the
HELIOS project we're funded to work on ;), although I'd like to extend
the reflection to other kinds of entities also. Bug ids (numbers ranging
from "3170" to "516315" at the time of writing) are pretty stable, and I
assume that URIs ending with them should be quite stable, then. Still we
would ideally need some URIs that are indeed URLs if possible, so maybe
something like http://bugs.debian.org/nnnnnn/+rdf or similar REST/URLs
may be usable. I still need to improve my understanding of LinkedData
and other Semantic Web techniques anyway ;-)

> For example, to reference a binary package for a specific arch, you
> can use some URI scheme containing binary package name, version, and
> architecture. You should do something similar for all keys of all
> packages (maybe you can come up with a generic URI scheme also
> including the UDD relation name?).
> 

What d'you mean by all keys of these packages ? 

> Alternatively, we can think together at URIs uniquely identifying
> tuples in each UDD table, and add an extra URI field to each such
> table. De facto, such new field will be a new key for the table, and
> you can use it to state facts (i.e., "triples" in the RDF lingo) about
> such objects.
> 
> I tend to prefer the latter option, how about you?
> 

We have to devise a prototype, test, and validate the real benefits...
but in the meantime, maybe all those questions will be already addressed
in a way that could transferable to Debian, by the SWIM/MEPHISTO guys.

I need to get rid of time consuming things (like writing papers, doing
reporting and having vacation) distracting me from that work, and talk
to my collegues @ Mandriva in Helios, and will surely be able to provide
better hints.

Thanks for the interesting discussion.

Best regards,
-- 
Olivier BERGER <olivier.berger@it-sudparis.eu>
http://www-public.it-sudparis.eu/~berger_o/ - OpenPGP-Id: 1024D/6B829EEC
Ingénieur Recherche - Dept INF
Institut TELECOM, SudParis (http://www.it-sudparis.eu/), Evry (France)


Reply to: