Re: my token about the "3 or more layer" structure for the ontology

Hello!

On Mon, Nov 24, 2008 at 11:47 AM, Pierre-Antoine Champin
<pchampin@liris.cnrs.fr> wrote:
>
> Hi Felix, thank you for your feedback.
>
> First, the term "data structure" was a bad choice. I should have written
> "conceptual model", which describes better what I am interested in. I
> think once we agree on a conceptual model, we can chose the best syntax
> to represent it -- if we want to...
>
> As a matter of fact, I took for granted that we would have to define our
> own format. But once again, the most important thing is the conceptual
> model.
>
> To be clear about my idea of a "conceptual model" or "ontology"... It
> does not necessarily implies that we describe it formally. You advocate
> a "prose" description, and it is indeed a possibility, as long as it is
> precise enough.
>
> However, that does not rule out, IMHO, the discussion about structure --
> and I still think structure is important for interoperability problems.
> I take an example:
>
> ID3 [1] has apparently a flat structure: it is a list of properties with
> text value. However, take the descriptions of the following properties:
>
>>   TALB
>>    The 'Album/Movie/Show title' frame is intended for the title of the
>>    recording (or source of sound) from which the audio in the file is
>>    taken.
>>
>>   TOAL
>>    The 'Original album/movie/show title' frame is intended for the title
>>    of the original recording (or source of sound), if for example the
>>    music in the file should be a cover of a previously released song.
>
> There is an awful lot of structure hidden in those flat properties!
> A sound file is *taken from* a *recording*, which has a *title* and can
> be an *album*, a *movie*, a *show* (and the list is probably not
> intended to be exhaustive). But it can have been *previously released*
> in another *recording*.
>
> So mapping those properties to, say, Dublin Core properties, not only
> requires to find an equivalence between the notion title, but also
> *taken from* (dc:source ?), *previously released* (??), etc...

Yes, ID3 is hiding a lot of structure. Lots of abstraction layers that
need to be addressed separately for expressing things such as "this is
another recording of the same performance" are smushed into one.
Did you check the music ontology [1], btw? There is already quite a
lot of data published using it, in quite a wide range of domain - see
top left of [2].

Cheers!
y

[1] http://musicontology.com
[2] http://esw.w3.org/topic/SweoIG/TaskForces/CommunityProjects/LinkingOpenData

>
>  pa
>
> [1] http://www.id3.org/id3v2.4.0-frames
>
>
> Felix Sasaki a ¨¦crit :
>> Hello Pierre-Antoine,
>>
>> Pierre-Antoine Champin ¤µ¤ó¤Ï•ø¤­¤Þ¤·¤¿:
>>> Felix,
>>>
>>> although I participated in putting the debate in terms of "XML vs. RDF",
>>> my concern was not about a precise syntax or foramt, and I agree with
>>> you that it should not be.
>>>
>>
>> Just for clarification: "agree that it should not be" means "we do not
>> need to define a syntax" or "we should not discuss XML vs. RDF, but need
>> to decide on a syntax"? If the latter, which syntax do you propose?
>>
>>> However in my view the question is more fundamental. Let me reword it.
>>>
>>> Designing an ontology involves, IMHO, a trade-off between faithfully
>>> representing the domain of interest, and projecting it in a practical
>>> data structure.
>>>
>>
>> Maybe here we already have different opinions: I think we can design an
>> ontology without a practical data structure. The current API / ontology
>> proposal does just that: defining a list of terms *as prose*. The data
>> structure related parts are only in the API, and in the prose mapping
>> descriptions.
>>
>>> Failthful in our context means:
>>> - able to cover a large part of legacy metadata
>>>   - able to satisfy most of the requirements of our use cases
>>>
>>> Practical in our context, means that the ontology should be:
>>> - easy to use by media publisher
>>> - easy to implement in browsers
>>>
>>> A very easy to use and implement data structure is a list of
>>> (attribute,value) pairs -- the so-called "flat" structure.
>>>
>>> By the way, even easier is a list of simple tags -- which can be tweaked
>>> into (attribute,value) pairs anyway, as pointed out by your previous
>>> mail about flickr.
>>>
>>> However, I think that this is too much of a simplification:
>>> - it does not satisfy come requirements (like the multi-level or
>>> collection) -- though we might decide that those ones are too complex
>>> - my intuition is that more structure would make "impedence mismatch"
>>> between legacy vocabularies easier to point out and solve
>>>
>>
>> I agree that this simplification does not cover many use cases like
>> "multi-level  or collection". But I also think for this version (1.0 of
>> the ontology / API) we should concentrate on the simple approach which
>> is important for all use cases and application scenarios. If that founds
>> adoption, we can shoot for 2.0 and a more complex approach.
>>
>> Btw., of course we have not described all application scenarios, use
>> cases and requirements yet. Nevertheless I think that the requirement to
>> get information across heterogenous formats is central to our WG.
>>
>> I don't think that more or less structure is related to the quality of
>> mapping between different vocabularies. For this mapping, detailed
>> knowledge brought in by the WG parcitipants about these vocabularies is
>> mostly important. If the mapping then is represented in prose, or as
>> more or less structured XML or RDF, is not important IMO. However, I do
>> think that a detailed prose description is important for the API, and it
>> can also help understanding a structured representation, if we decide to
>> do that.
>>
>> Felix
>>
>>>   pa
>>>
>>> Felix Sasaki a ¨¦crit :
>>>
>>>> Ruben Tous (UPC) ¤µ¤ó¤Ï•ø¤­¤Þ¤·¤¿:
>>>>
>>>>> Hi Pierre-Antoine, Silvia, all,
>>>>>
>>>>> I think that normalisation/denormalisation is related to the more
>>>>> general discussion about structured*/flat annotations (handling
>>>>> events, agents, etc. as separated structures) . The multi-level
>>>>> description discussion is probably a sub-topic within that general
>>>>> one, and refers only (as I've understood till now) to splitting
>>>>> (normalising) the main structure (the one describing the digital
>>>>> object) into several entities but only regarding different abstraction
>>>>> levels (e.g. document and instance).
>>>>>
>>>>> So, probably we should decide first about the structured*/flat
>>>>> question. If we choose "flat", then we could maybe discard also the
>>>>> multi-level description.
>>>>>
>>>>> Probably, there's a latent high-level question behind this discussion:
>>>>> will the ontology model the way annotations are interchanged, or will
>>>>> it model their underlying semantic grounding?
>>>>>
>>>>> Best regards,
>>>>>
>>>>> Ruben
>>>>>
>>>>> *When talking about structured annotations I'm not just referring to
>>>>> hierarchycal ones (XML), I refer to annotations with ObjectProperties
>>>>> (inlined or linked within the same annotation) (e.g. RDF).
>>>>>
>>>> Reading this discussion and the "features" wiki page, the "data model
>>>> rows", I have the impression that there is some tension between using
>>>> XML and RDF. I can understand that tension, but I think we should not
>>>> spend time on discussing it in this group. Nevertheless, it lets me more
>>>> and more think that we should not be format specific in our ontology,
>>>> but use just a prose description as the normative outcome, that is in
>>>> the "Ontology 1.0" Recommendation. If people want to write non-normative
>>>> RDF- and XML-formats, they are free to do so. I think we should focus on
>>>> formulating the terminology in the prose in a way that that makes a
>>>> formalization in whatever format straightforward.
>>>>
>>>> Felix
>>>>
>>>>
>>>>
>>>>
>>>>> ----- Original Message ----- From: "Silvia Pfeiffer"
>>>>> <silviapfeiffer1@gmail.com>
>>>>> To: "Ruben Tous (UPC)" <rtous@ac.upc.edu>
>>>>> Cc: <public-media-annotation@w3.org>
>>>>> Sent: Wednesday, November 19, 2008 10:10 PM
>>>>> Subject: Re: my token about the "3 or more layer" structure for the
>>>>> ontology
>>>>>
>>>>>
>>>>> Hi Ruben,
>>>>>
>>>>> It is always a matter of use cases.
>>>>>
>>>>> When we talk about management of collections, there will be overlap
>>>>> between the annotations of different files, which can be handled more
>>>>> efficiently (in a database sense: normalise your schema).
>>>>>
>>>>> However, if you receive an individual media resource, you want all of
>>>>> its annotations to be available with the media resource, i.e. you want
>>>>> an "intelligent" media object that can tell you things about itself.
>>>>>
>>>>> I don't see these things as separate. Let's take a real-world example.
>>>>> Let's assume I have a Web server with thousands of videos. They fall
>>>>> into categories and within categories into event, where each video
>>>>> within an event has the same metadata about the event. On the server,
>>>>> I would store the metadata in a database. I would do normalisation of
>>>>> the data and just store the data for each event once, but have a
>>>>> relationship table for video-event-relationships. Now, a Web Browser
>>>>> requests one of the videos for playback (or a search engine comes
>>>>> along and asks about the metadata for a video). Of course, I go ahead
>>>>> and extract all related metadata about that video from the database
>>>>> and send it with the video (or in the case of the search engine:
>>>>> without the video). I further have two ways of sending the metadata: I
>>>>> can send it in a text file (which is probably all the search engine
>>>>> needs), or I can send it multiplexed into the video file, e.g. as a
>>>>> metadata header (e.g. MP3 has ID3 for this, Ogg has vorbiscomment,
>>>>> other file formats have different metadata headers).
>>>>>
>>>>> I don't think we need to overly concern ourselves with whether we
>>>>> normalise our data structure. This is an "implementation" issue. We
>>>>> should understand the general way in which metadata is being handled
>>>>> as in the example above and not create schemas that won't work in this
>>>>> and other scenarios. But we should focus on identifying which
>>>>> information is important to keep about a video or audio file.
>>>>>
>>>>> Cheers,
>>>>> Silvia.
>>>>>
>>>>>
>>>>>
>>>>> On Thu, Nov 20, 2008 at 12:01 AM, Ruben Tous (UPC) <rtous@ac.upc.edu>
>>>>> wrote:
>>>>>
>>>>>> Dear V¨¦ronique, Silvia, all,
>>>>>>
>>>>>> I agree with both of you in that the need of multiple description
>>>>>> levels is
>>>>>> only related to a small subset of use cases, basically to those
>>>>>> related to
>>>>>> the management of groups of resources (e.g. digital asset management
>>>>>> systems, user media collections, etc.). Instead, we are (I guess)
>>>>>> focused in
>>>>>> embedded annotations in individual resources.
>>>>>>
>>>>>> However, I think that there are solutions which cover both cases, the
>>>>>> simple
>>>>>> and the complex one. For instance, we could embed the following
>>>>>> annotation
>>>>>> within an MPEG video:
>>>>>>
>>>>>> <mawg:Video rdf:ID=http://example.org/video/01">
>>>>>> <mawg:title>astronaut loses tool bag during spacewalk </mawg:title>
>>>>>> <mawg:creator>John Smith</mawg:creator>
>>>>>> </mawg:Video>
>>>>>>
>>>>>> <mawg:Resource rdf:ID="http://example.org/resource/01">
>>>>>> <mawg:format>FLV</mawg:format>
>>>>>> <mawg:filesize>21342342</mawg:filesize>
>>>>>> <mawg:duration>PT1004199059S</mawg:duration>
>>>>>> </ mawg:videoID rdf:resource="http://example.org/video/01">
>>>>>> </mawg:Resource>
>>>>>>
>>>>>> It is structured and it offers 2 abstraction levels, but it can be
>>>>>> serialized like a plain record. When appearing in isolated resources,
>>>>>> the
>>>>>> high-level annotation ("Video" in this case) would be repeated. When
>>>>>> appearing within a collection's annotation the "Video" annotation
>>>>>> would
>>>>>> appear just once.
>>>>>>
>>>>>> It is not so different than in XMP. Take to the following XMP
>>>>>> example...
>>>>>>
>>>>>> http://www.w3.org/2008/WebVideo/Annotations/wiki/images/8/8a/Xmp_example.xml
>>>>>>
>>>>>>
>>>>>>
>>>>>> Best regards,
>>>>>>
>>>>>> Ruben
>>>>>>
>>>>>>
>>>>>> ----- Original Message ----- From: <vmalaise@few.vu.nl>
>>>>>> To: <public-media-annotation@w3.org>
>>>>>> Sent: Wednesday, November 19, 2008 11:27 AM
>>>>>> Subject: my token about the "3 or more layer" structure for the
>>>>>> ontology
>>>>>>
>>>>>>
>>>>>>
>>>>>>> Hi everyone,
>>>>>>>
>>>>>>>
>>>>>>> I was at first very much in favor of an ontology that would
>>>>>>> distinguish
>>>>>>> different levels of media documents, like
>>>>>>> "work-manifestation-instance-item",
>>>>>>> but after reading this email from the list:
>>>>>>>
>>>>>>> http://lists.w3.org/Archives/Public/public-media-annotation/2008Nov/0076.html
>>>>>>>
>>>>>>>
>>>>>>> I agreed with the fact that we would probably only need a simple
>>>>>>> structure
>>>>>>> in
>>>>>>> our case, that multi-level structures were meant for linking
>>>>>>> different
>>>>>>> entities
>>>>>>> that have different status together: if we aim for linking the
>>>>>>> descriptions of a
>>>>>>> single item between different vocabularies, we need to specify if the
>>>>>>> single
>>>>>>> item is a work_in_XX_vocabulary, more likely a
>>>>>>> manifestation_in_XX_vocabulary
>>>>>>> (see note 1 below), to give its "type", and if people/use cases
>>>>>>> want to
>>>>>>> link
>>>>>>> this single item to other related works, manifestations, instances or
>>>>>>> items,
>>>>>>> they can use the framework defined in the schemas reviewed in
>>>>>>>
>>>>>>> http://www.w3.org/2008/WebVideo/Annotations/wiki/MultilevelDescriptionReview
>>>>>>>
>>>>>>>
>>>>>>> and use these properties for completing their description.
>>>>>>>
>>>>>>> So we would need a property like "has_type" to link a single
>>>>>>> description's
>>>>>>> identifier to the correct level of multilevel description schemes.
>>>>>>>
>>>>>>> I changed my mind think that only one "family" of use cases would
>>>>>>> need
>>>>>>> more
>>>>>>> levels, that they are somehow context dependent (and could thus be
>>>>>>> considered as
>>>>>>> requirements for a family of use cases), but of course if it turns
>>>>>>> out
>>>>>>> that more
>>>>>>> that one family of use cases needs this distinction, then we should
>>>>>>> consider
>>>>>>> going for a multilevel structure. Anyway, we would need to map
>>>>>>> informally
>>>>>>> the
>>>>>>> way these levels are expressed, in order to provide possible relevant
>>>>>>> "types"
>>>>>>> for the description of each single element.
>>>>>>>
>>>>>>> note 1: by specifying the different names of the relevant
>>>>>>> Concepts/terms
>>>>>>> in
>>>>>>> schemes like VRA, XMP etc., we would informally define a semantic
>>>>>>> equivalence
>>>>>>> between the ways these schema express these levels of description. It
>>>>>>> would look
>>>>>>> like:
>>>>>>> <metadataFile>
>>>>>>> <id="identifier">
>>>>>>> <hasType xmpMM:InstanceID, vra:image, frbr:item>
>>>>>>> </metadataFile>
>>>>>>>
>>>>>>> I think that the table
>>>>>>> http://www.w3.org/2008/WebVideo/Annotations/wiki/FeaturesTable
>>>>>>> is a very valuable tool for people to express their ideas about it,
>>>>>>> thank
>>>>>>> you
>>>>>>> very much Ruben for designing it!
>>>>>>>
>>>>>>> Best regards,
>>>>>>> V¨¦ronique
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>
>>>>
>>>
>>>
>>
>>
>
>
>

Received on Monday, 24 November 2008 11:59:51 UTC