On Fri, 2011-09-23 at 16:19 +0200, Sebastian Trüg wrote: > On 09/23/2011 04:08 PM, Sam Thursfield wrote: > >> this is the second time I send this email. Previously it had the subject > >> "Bookmarking - rebooted" and I fear that it scared away some people that > >> should actually be interested in this topic. The thing is just that from > >> my point of view the concepts are the same. So here goes again: > >> > >> Bookmarking is a rather simple concept. Typically used for URLs in web > >> browsers or file managers. In the Nepomuk ontologies (NFO) we have a > >> more or less direct mapping of the old bookmarking concept to classes: > >> > >> nfo:BookmarkFolder contains several nfo:Bookmarks which nfo:bookmarks > >> some nie:DataObjects. > >> > >> This is fine for the most basic kind of bookmarking: web urls and > >> files/folders. However, quickly the need for finer grained bookmarking > >> arose - a position in a text, a stream, and so on. Thus, properties like > >> nfo:pageNumber were created which give some information on the position > >> in the data object. > >> > >> >From my point of view this is not a great solution. For starters I do > >> not even like the concept of bookmarks. For me a bookmark is nothing > >> more than a piece of information that has been marked as interesting. > >> And with semantic search and friends I see no need for the organization > >> into bookmark folders anymore anyway. > >> > >> That aside I also think that we should not try to describe where in some > >> document our bookmark points to but we should rather properly define the > >> excerpt that we want to remember - a piece of text, part of an image, > >> and so on. Thus, we need to describe part of a nie:InformationElement. > >> Part of a nfo:PlainTextDocument for example is a piece of text which > >> starts at a certain character offset and has a certain length. To state > >> that a person is depicted in an image we should describe the part of the > >> image and then simply link that to the person. > >> > >> To me all this seems to happen on the nie:InformationElement level > >> rather than on the nie:DataObject level. We are interested in the > >> information, not the container. Thus, such a part of the document would > >> be nie:isLogicalPartOf the main information element. > > > > I fully agree with what you're saying. We need to strongly define > > 'excerpt' and 'bookmark' in this environment: an excerpt is a part of a > > logical resource, and a bookmark is essentially an annotation of this > > excerpt. The special case of bookmarks in a web browser sense is a bit of > > a trap because one annotates the whole resource (web page) instead of an > > excerpt. > > > >> What I am not sure about, however, is whether part of, say, a > >> nfo:RasterImage is a nfo:RasterImage again or if we need a dedicated new > >> type or if we would double-type. > > > > If we ignore any annotations to the excerpt (which count as bookmarks) > > there's no useful difference between nfo:RasterImage the whole image and > > nfo:RasterImage which is part of a larger one. > > > > I've been looking at this from an audio POV (I got here from > > https://sourceforge.net/apps/trac/oscaf/ticket/123 ) and the case of > > one audio file containing a whole album. A generic extract of a larger piece > > of audio is still nfo:Audio in my opinion. In the case that the extract is > > an entire track we can represent that by giving it type nmm:MusicPiece as > > well. > > I agree. > > >> In any case I would like to kick off the discussion of this topic which > >> is important in many situations by simply throwing some draft at you. > >> Have a look, comment on it, tell me that it is utter bs or that you like > >> the approach. Let's discuss. > >> > >> The draft: > >> ========================================== > >> > >> nie:Excerpt a rdfs:Class ; > >> rdfs:subClassOf nie:InformationElement . > >> > >> nie:containsExcerpt a rdf:Property ; > >> rdfs:subPropertyOf nao:hasSubResource, nie:hasLogicalPart ; > >> nrl:inverseProperty nie:isExcerptOf . > >> > >> nie:IsExcerptOf a rdf:Property ; > >> rdfs:subPropertyOf nao:hasSuperResource, nie:isLogicalPartOf ; > >> nrl:inverseProperty nie:containsExcerpt . > >> > >> > >> nfo:TextExcerpt a rdfs:Class ; > >> rdfs:subClassOf nie:Excerpt . > >> > >> > >> // can this be a nfo:Visual? > >> nfo:ImageRegion a rdfs:Class ; > >> rdfs:subClassOf nie:Excerpt . > >> > >> nfo:RectangularImageRegion a rdfs:Class ; > >> rdfs:subClassOf nfo:ImageRegion . > >> > >> nfo:offsetX a rdf:Property ; > >> rdfs:domain nfo:RectangularImageRegion ; > >> rdfs:range xsd:integer . > >> > >> nfo:offsetY a rdf:Property ; > >> rdfs:domain nfo:RectangularImageRegion ; > >> rdfs:range xsd:integer . > >> ========================================== > > > > I'm not convinced that the separate heirarchy for excerpts > > is necessary. nfo:Image is an ugly case because it's defined > > as "a file containing an image". I see something more like > > I think we could simply change that.
Yes, we could have both nie:Image and nfo:Image which is a little nasty but would avoid breaking compatibility .. > > this would make sense: > > > > nie:Image a rdfs:Class ; > > rdfs:subClassOf nie:InformationElement > > > > nie:RasterImage a rdfs:Class ; > > rdfs:subClassOf nie:Image > > > > nfo:ImageFile a rdfs:Class ; > > rdfs:subClassOf nfo:FileDataObject > > actually no. There is the file and then there are its contents. The > former is a FileDataObject and the latter a RasterImage. By using > doube-typing as we do now everything already works out fine. We only > need to change the rdfs:comment on the image class (which is wrong > anyway since an image can also be embedded in an attachment or an > archive, so it does not have to be a file) I think we're agreeing here :) > > We use an nie:Image to represent the whole file, linked to the > > nfo:ImageFile resource using nie:isStoredAs. We can then use > > nie:isStoredAs is conceptually correct but in Nepomuk we do not use it > as we combine the DataObject and Informationelement into one - as > mentioned above. Interesting, in Tracker we do the same but also have _:file nie:isStoredAs _:file > > nie:isLogicalPartOf to link image excerpts to the larger image, > > using a set of new properties to describe the containment: > > > > # Vector offset [0, 1] > > nie:imageOffsetX a rdf:Property ; > > rdfs:domain nie:Image ; > > rdfs:range xsd:double . > > nie:imageOffsetY a rdf:Property ; > > rdfs:domain nie:Image ; > > rdfs:range xsd:double . > > > > # Pixel offset > > nie:rasterImageOffsetX a rdf:Property ; > > rdfs:domain nie:RasterImage ; > > rdfs:range xsd:integer. > > nie:rasterImageOffsetY a rdf:Property ; > > rdfs:domain nie:RasterImage ; > > rdfs:range xsd:integer. > > could be sub-properties of the above. Very true > > > > For audio, a similar thing works: > > > > # Offset in seconds > > nie:audioOffset a rdf:Property ; > > rdfs:domain nfo:Audio ; > > rdfs:range xsd:double . > > sounds good to me. > > (As an aside, the other conceptual way to implement this > > would be by specifying URI schemes for specifying regions, eg. > > > > file:///foo.mp3#15502.33 (seconds) > > file:///foo.jpg#40,50-500,600 (pixels) > > I would like to avoid parsing of URIs actually. > > > This is inherently less robust than specifying the properties in RDF because > > we can't specify units, range etc and there will have to be some special > > URI parsing > > code to handle them. I'm bringing it up pre-emptively to show it's a bad > > idea :) > > hehe > > > Hope these thoughts are in some way helpful. > > very. For the moment this seems like a good idea to me. I suppose I need > to write it down and propose it as a patch before I can get a final view > on things. I'm liking the sound of everything here, look forward to seeing the patch :) Sam _______________________________________________ Nepomuk mailing list [email protected] https://mail.kde.org/mailman/listinfo/nepomuk
