[Xesam] Link-by-id documentation and ontology patching

[Mikkel Kamstrup Erlandsen]

2009/1/11 Evgeny Egorochkin <phreedom.stdin at gmail.com>

First sorry for the late response. Work and sick kids has kept me with very
little screen time lately.

> First: Are we talking xesam:creator only here or are we discussing a more
> > general idea?
>
> xesam:creator is more or less treated as an exception or as a properly
> typed
> version of original link-by-id
>

<SNIP>


>
> > 1) xesam:creator chilren are allowed to only link to xesam:ContactMedium
> of
> >
> > > xesam:Contact, which is consistent with the way it's usually done in
> RDF
> > > world.
> > >
> > > 2) Links by ID between documents are resolved directly to URI of the
> > > document(s) if it exists, or a dummy Document of appropriate type is
> > > created with ID assigned to it and xesam:Source set to
> xesam:Unavailable.
> > >
>
<SNIP>

>
> > We still want globally unique IDs, no? I can't see how that is possible
> > without URI schemes
>
> Yes, ID field values won't be globally unique then. Only values of a
> particular field stay unique.
>

Ok, then you have to know the exact field to search for the id in to get the
object of a given id.


> > * direct links work much faster
> >
> > What do you mean direct link? You link to BookB via its URI user:BookB
> just
> > like one would use any other id...
>
> You'd have to have an index for every id field for this to work fast enough
> and still you have several times more uris to match. Of course the
> performance penalty greatly depends on the rdf/sql backend.
>

You are suggesting that xesam:contactMedium would be the only id because of
performance reasons? xesam:contactMedium would by far contribute the biggest
number of id fields anyway... 15 from contactMedium and 3 others.


>
> > * documents can't be authored by audio files
> >
> >
> > This is a bit academic, but true.
>
> Not too academic though since you can expect to confront software with
> metadata it's not fully aware of with the only available description being
> an
> ontology.
>

Unless you add a whole verification layer to the metadata storage you can
never expect anything from the metadata. And with my experience in this I
don't think this is feasible on the desktop (not if you want to check
relations and such that is).


>
> > I must admit that I am pretty lost here... I this all about making
> > xesam:creator a relation-but-not-quite?
>
> More like dropping link-by-id for everything but creator :)
>

I just really like the idea of making relations between files based on their
md5 sums for instance. This makes it "free" to keep persistent user metadata
across file moves.

Generally I am not overly keen on your idea. However if linking stuff to
contacts is our 95% use case then I can better justify your proposal, but as
I see it this just isn't the case.

To re-iterate your proposal:

1) xesam:creator (and children) must contain values from the
xesam:contactMedium field of a xesam:Contact

2) All other relations use xesam:url for linking

I can see 1) working if we just specify in xesam:creator that it must
contain an child of xesam:contactMedium that is an id. The only child of
xesam:contactMedium that is not an id is xesam:physicalAddress...

I think we can skip 2) because the performance impact of the 3 extra id
fields shouldn't be big.

-- 
Cheers,
Mikkel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.freedesktop.org/archives/xesam/attachments/20090123/97a78af5/attachment.html