- From: Morten Frederiksen <mof-rdf@mfd-consult.dk>
- Date: Wed, 21 Jan 2004 01:00:49 +0100
- To: semantic-photolist@unitboy.com
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 UTC