W3C home > Mailing lists > Public > semantic-web@w3.org > January 2006

Re: Newbie frustrations

From: Christian Halaschek-Wiener <halasche@cs.umd.edu>
Date: Tue, 10 Jan 2006 10:43:24 -0500
Message-Id: <C4422F98-EC98-4BD3-BCF9-76553535C0E8@cs.umd.edu>
Cc: semantic-web@w3.org
To: wollman+semantic-web@bimajority.org

Hi GAWollman,

I have addressed a few of your questions/comments. Hope they help in  
one way or another. You may also want to check out the current  
progress of one of the W3C's task forces, the Multimedia Task Force  
(http://www.w3.org/2001/sw/BestPractices/MM/). We are working towards  
publishing our first deliverable on image annotation on the Semantic  
Web. Currently, the document is an editor's draft, however, it may  
provide you with some insights...http://www.w3.org/2001/sw/ 
BestPractices/MM/image_annotation.html

> My first difficulty was in how to contain the information explosion.
> In a typical 75-photo gallery, there are 376 distinct resources: one
> index page, 75 thumbnails, and a description page and image file for
> each of two resolutions.  But in the abstract "photo gallery"
> semantics, there are only 151 actual *things*: an index page, possibly
> with extended narrative, 75 photos, and 75 photo captions.  It's not
> at all clear how to represent this.

In my experience with our image annotation tool, PhotoStuff [1,2] and  
our portal work (see one of our deployments, SemSpace [3]), we  
modeled this using some reuse/extensions of foaf by creating a  
multimedia ontology [4]. We didnt actually treat the index pages as  
resources, rather just images and their relations (e.g., depictions  
of instances,  descriptions, etc) and then let the server side  
scripts handle the presentation (based on the types of resources  
clicked by the user).

It seems that your current abstract "photo gallery" would only have  
three actual *things*: 1 index page concept (possibly with an  
extended narrative), 1 photo concept, and 1 caption concept. Am I  
missing something? If you were to adopt an approach such as ours, you  
would avoid the index page concept.


> I ended up (after trying several
> alternatives that were unsatisfactory) representing each abstract
> photo and each abstract caption as named blank nodes, with a

Why not use foaf:Image for the abstract photo concept? Again I may be  
misunderstanding your intended use of an abstract photo...

> dcterms:hasFormat property indicating each of the available sizes.  (I
> never figured out how to use rdf:Bag or rdf:Alt for this last bit, so
> each hasFormat property is written separately.)  Then the abstract
> photo can refer to the abstract caption for its dc:description
> property, and at least some of the implicit semantic structure is made
> explicit.
>
> The next problem was also an information explosion, and I see from the
> archives of this list that it's a well-traveled road.  Each photo
> description in my source file has a photographer attribute.
> Originally, this was only used to automatically generate copyright
> notices on each page, so all I have is the name of the photographer in
> conversational order.  This is an obvious candidate for inclusion in
> the gallery metadata.  My first implementation simply output the
> photographer name as a literal in the dc:creator property, but I felt
> like I ought to be able to better.  I knew, in particular, that users
> might want to use the foaf vocabulary to describe individuals depicted
> in their photos, so I decided to represent photographers as instances
> of foaf:Person.  The naive approach of using a foaf:Person as a value
> of the dc:creator property failed to represent the important
> underlying expectation that two photographers with the same name in
> the same gallery are the same person.  So again I used the
> named-blank-node approach (which obviously only works because I
> keep the metadata for the whole gallery in a single document).  But in
> this case it's rather less than satisfactory; I was forced to use the
> generate-id() XPath function to create the names, which means that the
> author of the gallery has no way of adding additional properties to
> one of these automatically-generated foaf:Person instances.  I may end
> up removing this function entirely and requiring the user to handle
> this herself -- which I already do for the textual elements, since
> my DTD doesn't represent authorship of the descriptions.
>
> Having made an initial proof-of-concept hack, I started to annotate an
> existing photo gallery with metadata, and quickly ran aground.  There
> are four obvious categories of metadata one might be interested in for
> an individual photograph:
>
> a) Technical: how the photo was taken, at what resolution, in what
> orientation, etc.  I am mostly not concerned with this, since it is of
> no value to my application.

Check out the EXIF RDF schema available at [5]

>
> b) Temporal: when the photo was taken.  This is easy to accomplish and
> the choice of representation is obvious.  (I used dcterms:created and
> represent the date in DTF.)
>
> c) Geographic: where was the photo taken.  This was much more
> difficult; the obvious schemas all took a very computer-oriented
> approach to geocoding, representing locations as grid coordinates --
> information I do not have.  I searched for hours looking for a good
> representation of an ordinary street address (the only kind of
> geographic location I might have access to for my photos) and didn't
> find anything I would describe as "good".
>
> d) Subject matter: what is this a photo of?  It seems that here I have
> to develop my own ontology, since I don't tend to take photos of
> airports and only rarely take photos of people (where foaf provides
> everything that's required).

As Richard said a few days ago, foaf:depicts should be sufficient for  
this.


>
> I take pictures of radio towers.  Most towers have a number, assigned
> by the FCC, but some don't.  All I wanted was a way to represent
> "photo X shows tower Y" in a way which would allow me to answer
> queries like "show me all the photos of tower Y in temporal order".
> It shouldn't be this hard!
>
> Sorry for the long-winded rant.  Am I being unreasonable or is it
> really expected to be this difficult?
>
> -GAWollman
>
>


Anyway, I hope this helps...

Cheers,
Chris

[1] PhotoStuff Project Homepage: http://www.mindswap.org/2003/ 
PhotoStuff/
[2] C. Halaschek-Wiener, A. Schain, Jennifer Golbeck, M. Grove, B.  
Parsia, and J. Hendler. A Flexible Approach for Managing Digital  
Images on the Semantic Web, SemAnnot2005. Available at http:// 
www.mindswap.org/~chris/publications/PhotoStuffSemannot2005.pdf
[3] SemSpace Web portal - Photo browsing. Available at: http:// 
semspace.mindswap.org/photos/
[4] Digital Media ontology: http://www.mindswap.org/2005/owl/digital- 
media
[5] EXIF RDF Schema: http://www.w3.org/2003/12/exif/




-- 
Christian Halaschek-Wiener
PhD Student, Dept. of Computer Science
GRA, MINDSWAP Research Group,
University of Maryland, College Park
Web page: http://www.mindswap.org/~chris
Received on Tuesday, 10 January 2006 15:43:30 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:47:11 UTC