W3C home > Mailing lists > Public > www-archive@w3.org > January 2004

[w3photo] Image regions

From: Morten Frederiksen <mof-rdf@mfd-consult.dk>
Date: Wed, 21 Jan 2004 01:00:49 +0100
To: semantic-photolist@unitboy.com
Message-Id: <04012101004900.01105@zonker.mfd-consult.dk>


Hi there,

We had an IRC chat meet tuesday on parts of images, and Jim and I was
actioned to send a schema and sample document, based on the agreement
reached.

We discussed photos versus multimedia, but decided that since the project
starts out with just photos, we would just leave room in the model for
later additions of other types of media. Also because of this, it was
decided that the classes and properties would be named specifically for
photos, as general names were hard to find.

We looked at the schemas currently out there, including Jim's new thoughts
[1], Jennifer's [2] and Masahide's [3], and came up with the following
classes and properties (we didn't discuss the namespace, so the
BuildOrBuyTerms issue is still open):

Classes:
- Image
- Region (subclassed into Polygon, Circle etc.)

Properties:
- hasRegion (with inverse regionOf)
  * domain: Image
  * range: Region
- regionDepicts (with inverse regionDepiction)
  * domain: Region
  * range: Resource (Person, perhaps a wordnet concept, anything etc.)

With this schema [4] (example: [5]), it should be possible to later add 
superclasses and -properties to include other types of multimedia.

Additional notes:
- The inverse properties were added post-meeting.
- The word "region" was debated, other suggestions included segment,
  section, area, part, shape, thingy, element, segmentation, extent and
  component. For photos region was agreed upon as the best option.
- We decided that, for now, it'd be best to keep a depicts property
  with a domain of Image separate from regionDepicts, to avoid confusing
  existing tools that expect a URI for the subject.

Later we discussed how to describe the region itself. We agreed that this
should be a simple literal property, for ease of use and to avoid security
issues, validating/handling SVG in general doesn't seem feasible for
all...

We agreed to disagree on the modelling of the description, but agreed on
SVG and came up with two approaches and two extensions:
- A single property for alle types of regions, using SVG's general
  path-syntax [6], with a property name like "outline".
  + With this approach, it could be handy with a boundingBox property
    alongside the outline property. The bounding box would then be
    computed by clients generating "complex" shapes, and consumed by
    clients not able to handle those shapes. This property would be a
    "SHOULD" in the "spec" (as opposed to the outline, which would be
    a "MUST").
- A property for each type of region, named after the region type, using
  a subset of SVG's basic shapes [7]: circle, ellipse and polygon
  (instead of polyline, to avoid repeating end-point, and semantics of
  polyline indicate that "typically, polyline elements define open
  shapes").
  + It could be handy to also include rect[angle] in this list, even if
    it's a subset of polygon.

After the meeting, Jim and I discussed the issue again [8], reaching
a compromise for a solution proposal:
- One property, coords, for circle, polygon and rectangle, with a domain of
  Region and a range of Literal. To keep compatibility with HTML image
  maps [9] and SVG, it seems the syntax from the former (which is also
  acceptable by the latter) should be adapted, with circles being defined
  by "point,radius", rectangles by "point,point" and polygons by
  "point,point,...". Separation of coordinates in a point is also done by
  ",", only integer coordinates are allowed, and the ending point in a
  polygon is omitted (auto-close).
- An ellipse could be defined by "point,x-radius,y-radius", which would
  be compatible with SVG but not HTML image maps. A fallback method
  could be to transform it into a circle, using the larger radius.
- The interpretation of the coords property is done by inspecting a
  suitable rdf:type property of the Region (Circle, Polygon, Rectangle or
  Ellipse).
- Additional, more complex region types could be added at a later date
  by using SVG's path syntax.
- A boundingBox property MAY be added by generating client, but could
  be computed easily for the basic shapes. When using more complex shapes
  and SVG's path syntax, the boundingBox property SHOULD be added.


Jennifer and Masahide couldn't make the meeting, but we hope they will
chime in here on the list instead, nothing is set in stone...


[1] http://jibbering.com/discussion/image.1
[2] http://www.mindswap.org/~glapizco/technical.owl
[3] http://kanzaki.com/works/2004/imgdsc/0106.html
[4] http://www.wasab.dk/morten/2004/01/image-regions-schema.rdf
[5] http://www.wasab.dk/morten/2004/01/image-regions-sample.rdf
[6] http://www.w3.org/TR/SVG11/paths.html
[7] http://www.w3.org/TR/SVG11/shapes.html
[8] 
http://www.ilrt.bris.ac.uk/discovery/chatlogs/rdfig/2004-01-20.html#T21-22-02
[9] http://www.w3.org/TR/html401/struct/objects.html#h-13.6.1


Regards,
Morten
=================
This is the TEMPORARY discussion list for the W3 Semantic-Photo History
Project. For questions, contact greg@fotonotes.net.

Subscribe Instructions
To:   semantic-photolist-request@unitboy.com
Body: subscribe

Unsubscribe Instructions
To:   semantic-photolist-request@unitboy.com
Body: unsubscribe

Help
To:   semantic-photolist-request@unitboy.com
Body: help
Received on Tuesday, 20 January 2004 18:59:34 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 7 November 2012 14:17:39 GMT