Recommend StillImage instead of Image?

[azaroth42]

dcterms:Image is the superClass of StillImage and MovingImage. Should we instead replace the recommendation for Image with StillImage to avoid potential inferential confusion?

[tilgovi]

Seems reasonable.

[azaroth42]

When we drop namespace prefixes from classes, we can map in the json-ld context from Image to dctypes:StillImage :) And potentially Video to dctypes:MovingImage ?

[rtroncy]

Video is more than MovingImage. Why not considering the concepts of Image or VideoTrack from the ma-ont namespace? Or borrow classes from schema.org such as ImageObject and VideoObject?

[azaroth42]

@rtroncy - dctypes:Image (let alone MovingImage) explicitly includes film, so audio components don't seem out of the question. http://dublincore.org/documents/2012/06/14/dcmi-terms/?v=dcmitype#Image

If we went to schema.org types:

• AudioObject
• ImageObject
• VideoObject
• DataSet
• WebPage
• SoftwareApplication

But there's no Text Document to replace dctypes:Text ("A resource consisting primarily of words for reading."), so we would be just moving problems around. @danbri might have a suggestion?

[rtroncy]

Given that this issue will be discussed during the December 2, 2015 telecon, what is the exact proposal here? We recommend to use the dctype classes, and in particular, either StillImage or MovingImage? My problem with those classes is that there is nothing for Audio objects (your mp3 files don't have visual).

There is a Text class in schema.org. What's wrong with the classes defined in the W3C Media Annotations ontology?

[azaroth42]

For http://www.w3.org/TR/mediaont-10/ , there only appears to be media related classes, whereas the desire is for a broad set, similar to dctypes (which we have already been using), schema.org, or activitystreams. So I don't think that's appropriate for this particular use case.

To clarify the proposal:

• Accept the MovingImage / StillImage distinction that's already in the current published draft document :) See: http://www.w3.org/TR/annotation-model/#classes
• Add statements to the effect that we consider the appropriate classes from schema and activitystreams and any others that can be identified as equivalent, assuming that the -vocab split is accepted: http://w3c.openannotation.org/add_vocab/vocab/wd/#dctypes-movingimage

And Jacob, I don't understand why you think we're using strings rather than URIs to identify these classes? "Video" is an alias for the URI http://purl.org/dc/dcmitype/MovingImage in JSON-LD only, and turning it into triples would result in that URI.

[rtroncy]

Thanks for the proposal clarification. No objection from my side and +1 for adding statements pointing to other possible vocab when relevant (or for asking for community/implementation feedback).

Jacob, I was not aiming to trigger a political discussion but was very pragmatically judging each vocab on their own merits, which includes the way classes are defined (labels and comments count) and how much those vocab are already adopted, acknowledging that this is relatively subjective.

[iherman]

Accepted "use StillImage and relate to other ontologies in -vocab" see http://www.w3.org/2015/12/02-annotation-irc#T16-54-04

[azaroth42]

Done (to some degree, needs finishing for other classes) http://w3c.github.io/web-annotation/vocab/wd/#classes-1 and http://w3c.github.io/web-annotation/vocab/wd/#json-ld-considerations