RE: Test implementation

Dear Pierre-Antoine,

Thanks for viewing my implementation approach. You can find my comments inline.

Kind regards,

Chris

-----Original Message-----
From: public-media-annotation-request@w3.org [mailto:public-media-annotation-request@w3.org] On Behalf Of Pierre-Antoine
Sent: donderdag 26 november 2009 10:37
To: Chris.Poppe@UGent.be
Cc: public-media-annotation@w3.org
Subject: Re: Test implementation

Hi Chris,

very nice work. A few comments :

* I agree that the metadata-source should be present, however, I think
  the URI of that source is more valueable that a label describing its
  type (or is this just a matter of presentation?)

[CP] The label is in fact the id of the image embedded in the HTML page. But under the hood this identifier is indeed mapped to the URI of the resource.

* in MediaRDF2, strictly speaking, the URI of the creator should be
   http://multimedialab.elis.ugent.be/users/chpoppe/JohnDoeFoaf.rdf#JD
  (#JD is missing in your example) and the RDF file should use
  rdf:about="#JD" instead of rdf:nodeID="JD"

[CP] I agree

* in MediaRDF2, why keep the URI for the unstructured value rather than
  "John Doe", which you can extract or build from the FOAF profile,
  since you fetch it anyway?

[CP] This is a hard one. I would assume that if you want the unstructured value, you also want to do the interpretation of this value yourself. Hence the original URI is passed so that the application can decide what to do with it.


* about "First name" and "Family name", is this something that we
  intend to normalize at the API level? What if the creator is an
  organization instead? Although I think this information can be
  useful and is often present, isn't it a little too ad-hoc?

[CP] Well this brings us back to the return type of such a method. In my implementation I currently only regard "person" creators. Since almost all metadata formats that I included do allow to specify first and family name I indeed think it could be useful to add this to the API (and even the ontology). The reason for me is just the same as the reason why we allow to retrieve the creator; it is something that is common in most metadata standards. 

* why do the return values for "Identifier" not contain a "URI" field?
  I note that the Ontology and API documents disagree on that property:
  Ontology says it *is* a URI, while API says it only SHOULD be.
  Either way, let's be explicit about it being a URI.

[CP] Well the main reason for me was that the definition of the identifiers in the metadata formats are not URI's in an internet sense but more an unique identifier according to some identification mechanism. (DIG35 allows to define the identifier (a string) and the identification system (through an URI))(Dublin core just sais that the identifier is "An unambiguous reference to the resource within a given context" and "Recommended best practice is to identify the resource by means of a string conforming to a formal identification system"). Moreover, I see the URI property as an URI to additional metadata (e.g., like in the foaf case the URI property holds an URI to the foaf creator).
But maybe I am way of here :) 


 pa

Le 25/11/2009 13:42, Chris Poppe a écrit :
> Dear all,
> 
>  
> 
> The last days I spent some time on an implementation of the API, 
> basically the main reason why I did not actively participated in the 
> discussions on the subproperties.
> 
>  
> 
> You can find my “raw” WIP test-implementation (tested with IE 8 and 
> Firefox 3.5.5) at:
> 
> http://multimedialab.elis.ugent.be/users/chpoppe/MediaAnnotations.html
> 
>  
> 
> This page uses JavaScript (note that currently only JavaScript or Java 
> bindings are defined for the WebIDL language!).
> 
> A javascript library holds the implementation of the method:
> getProperty(propertyName, sourceFormat, subType, language, fragment).
>  This library currently (tries to) parse XML, RDF and EXIF.
> 
>  
> 
> To test it, first a mediaresource needs to be selected (there is only
> one: the image in the page). Then you can choose getProperty for a 
> specific property. If a sourceformat is selected it is  passed as the 
> optional parameter ‘sourceFormat’.
> 
> The result is an array of objects.
> 
> Each object holds:
> 
> ·          an unstructured value (string) which is a textual label
> holding the values.
> 
> ·         a sourceFormat (to denote from which sourceformat this
> information is extracted). Note that this is not part of the API for 
> now but I think it might be valuable.
> 
> ·         An URI if this is available in the sourceFormat (Currently
> only MediaRDF holds URI’s but even in this case you cannot be sure 
> that it is actually an URI …)
> 
> ·         More properties (which could be called sub-properties),
> depending on the requested property
> 
> o   For example if you request for the creator you get back:
> 
> sourceFormat: MPEG-7
> Unstructured value: John Doe
> First Name: John
> Family Name: Doe
> URI: undefined
> 
> The unstructured value gives no information at all! Meaning you can 
> *not
> * assume that John is the firstname. Since many metadata formats allow 
> to define the first and family name I added these to the returned 
> object of getProperty(“creator”)
> 
>  
> 
> o   For the MediaRDF you get back 2 objects (corresponding to the two
> metadata files):  
> 
>  
> 
> sourceFormat: MEDIARDF
> Unstructured value: John Doe
> First Name: undefined
> Family Name: undefined
> URI: undefined
> 
> sourceFormat: MEDIARDF
> Unstructured value:
> http://multimedialab.elis.ugent.be/users/chpoppe/JohnDoeFoaf.rdf
> First Name: John
> Family Name: Doe
> URI: http://multimedialab.elis.ugent.be/users/chpoppe/JohnDoeFoaf.rdf
> 
>  
> 
> In this case, my implementation actually parses the Foaf description 
> of the creator to retrieve the relevant information like first name 
> and family name
> 
>  
> 
>  
> 
> o   When you request for contributor you get back:
> 
> sourceFormat: MPEG-7
> Unstructured value: John Doe
> First Name: John
> Family Name: Doe
> role: creator
> URI: undefined
> 
>  
> 
> sourceFormat: DC
> Unstructured value: Doe, Jane
> First Name: undefined
> Family Name: undefined
> role: publisher
> URI: undefined
> 
>  
> 
> Here you can see that a “role” property is added which denotes what 
> kind of contributor we are talking about. This is related to the 
> proposition by Pierre-Antoine, he suggested:
> 
> md.getValues("contributor")
> 
>  
> 
> returning
> 
>    [ { "value": "John Doe", "subproperty": "id3:composer" },
> 
>      { "value": "Jane Doe", "subproperty": "id3:lyricist" };
> 
>    ]
> 
>  
> 
> The terms ‘creator’ and ‘publisher’ that I return are currently chosen 
> by me.
> 
>  
> 
> Kind regards,
> 
> Chris
> 
>  
> 
> Ghent University - IBBT
> Faculty of Engineering
> Department of Electronics and Information Systems (ELIS) Multimedia 
> Lab Gaston Crommenlaan 8 bus 201 B-9050 Ledeberg-Ghent Belgium
> 
>  
> t: +32 9 33 14959
> f: +32 9 33 14896
> t secr: +32 9 33 14911
> e: chris.poppe@ugent.be <mailto:chris.poppe@ugent.be>
> 
>  
> 
> URL: http://multimedialab.elis.ugent.be
> 
>  
>

Received on Thursday, 26 November 2009 12:30:02 UTC