2009/1/11 Evgeny Egorochkin <[email protected]> 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
_______________________________________________ Xesam mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/xesam
