2007/6/1, Antoni Mylka <<a href="mailto:antoni.mylka@dfki.uni-kl.de">antoni.mylka@dfki.uni-kl.de</a>>:<div><span class="gmail_quote"></span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Mikkel Kamstrup Erlandsen pisze:<br>><br>> * contributor (DC)<br>> * creator (DC)<br>> * description (DC)<br>> * language (DC)<br>> * publisher (DC)<br>> * subject (DC)<br>> * title (DC)<br>
> * license (an extensible vocabulary with predefined values GPL, LPGL,<br>> MIT etc)<br>> * uri<br>> * category (a controled vocabulary that maps to the cats in the<br>> extended onto)<br><br>This particular one may be tricky. This "controlled" vocabulary should
<br>be extensible. I think it's not a good idea to have to agree on all<br>categories at the very beginning. I would rather go for the notion of<br>type. A resource may be a file, email whatever. This field would point
<br>at a type of a resource. (In NIE it would be expressed with rdf:type<br>pointing to an URI of a class (like Document, File or whatever), in the<br>simplified XESAM "language" it could point at some type identifier).
</blockquote><div><br>What you call "type" is what we have called "Source" so far I think. The category of an object is fx Contact, Video, Image or the likes. The source specifies how we obtained this object fx EmailAttachment, File, Archive...
<br><br>I agree that the vocabulary should be extensible, but it should still have predefined values.<br><br>Evgeny pointed out on IRC that the above proposal was to simple to be usable. Things like Contacts and Email does not really fit into it in a natural way. He had a proposal coming up with a bunch of extra fields that should accomodate this if I'm not mistaken. Evgeny?
<br></div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">The question if you want to have a simple list of types, or an<br>inheritance tree of types remains open.
</blockquote><div><br>It will be a tree. At least that's what we've settled on at the 2007-05-15 meeting.<br></div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
> * mime<br>> * creationDate<br>> * modificationDate<br>><br>><br>> With this simple onto you can actually do quite a bit of nifty stuff.<br>> With this in place it might also be easier to agree on extended ontology
<br>> as Antoni already suggested.<br>><br><br>I'm all for. With this set (or something similar) it should be possible<br>to agree on a 1 to 1 mapping between NIE-core and XESAM-core.<br><br>The properties from the extended part of the ontology could be mapped
<br>via the subproperty relations to the ones from core (as much as<br>possible). A simple mechanism could realise the basic inference rule.<br><br>IF a prop b AND prop subPropertyOf prop2 THEN a prop2 b<br><br>This shouldn't be too difficult and time-consuming, even in systems
<br>where performance is a priority.</blockquote><div><br>Right, I think most indexers can (and does) support this already. Anyway it has always been an unspoken premise of the field ontology that we used inheritance.<br>
<br>Is it possible that you can change you vocabulary when you talk xesam? :-) We use "field"[1] by convention and you call them "properties" (which ofcourse is the correct rdf lingo). It could reduce the possibilities of confusion a bit :-)
<br></div><br>Cheers,<br>Mikkel<br><br>[1]: This seems to be the standard term used in most indexers where a field value is always a literal (as it is in xesam)<br></div>