W3C home > Mailing lists > Public > public-media-annotation@w3.org > November 2008

Re: URIs as value

From: Felix Sasaki <fsasaki@w3.org>
Date: Wed, 12 Nov 2008 08:01:31 +0900
Message-ID: <491A0ECB.7010904@w3.org>
To: Silvia Pfeiffer <silviapfeiffer1@gmail.com>
CC: Pierre-Antoine Champin <swlists-040405@champin.net>, public-media-annotation@w3.org

Hi Silivia, Pierre-Antoine, all,

Silvia Pfeiffer さんは書きました:
> On Wed, Nov 12, 2008 at 9:12 AM, Pierre-Antoine Champin
> <swlists-040405@champin.net> wrote:
>> Hi all,
>> since I was only on IRC for the last telecon, I may have miss some part
>> of the debate. However, I would like to develop on my suggestion to
>> allow URIs or strings in properties such as dc:creator.

Just a general comment / remark: I know it sounds boring, but ... I 
think we should focus on what is current, more or less widely deployed 
practice with existing formats. After all we are scheduled to provide 
interoperability between properties of these formats and not define new 

>> Imposing a particular structure to a property may raise some issues,
>> related for example to internationalization. So simple strings seem to
>> be a nice fallback option.
>> However, it would be a shame to ignore more precise information when it
>> is available (for a string may be quite ambiguous, e.g. "Pierre-Antoine
>> Champin", "P-A. Champin", "Pierre-A Champin"...). It is out of scope to
>> provide an ontology for describing persons, but if such an ontology
>> exists out there, why not allow to use it when it is available (e.g.
>> http://champin.net/foaf.rdf#me).

The question is really what you mean by "available". Sure, foaf has 
URIs, but normally foaf is not applied to multi media objects AFAIK. My 
prosal here is basically the same as before: let's concentrate on 
interoperability between what's out there.

>> So I think both should be possible: string for simplicity, URI for
>> expressivity. May be both could be mixed, e.g. like in mail addresses:
>>  dc:creator "P-A. Champin <http://champin.net/foaf.rdf#me>" .
>> Now, that raises the question of the kind of URI we require. I have an
>> RDF background, I would tend to say: any URI, it is up to the
>> application to retrieve the description of that URI. If it follows good
>> practices, it should be possible to retrieve the description by GETting
>> it (requesting application/rdf+xml) but that may not be the only way to
>> obtain a description... and prescribing one is out of scope of the WG, I
>> think.
>> That also raises the question of the API: should it be able to retrieve
>> and access the RDF triples associated to the URI value of a property
>> from the ontology?
> I actually really like this idea - and the RDF focus. Many people will
> be moving towards describing meta information in RDF/foaf elements, so
> describing a way to integrate media annotations with this new
> knowledge base is really important.

Saying "we provide an RDF based format and mandate its usage in the API" 
is like an invitation to browser vendors not to implement the API. I 
think that would be a mistake. Remember that still we mostly have people 
from the academic world on board. I don't want to loose them, but want 
to have an approach which encourages more particiation from also that 

Received on Tuesday, 11 November 2008 23:02:12 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 16:24:30 UTC