Re: Test implementation

Le 26/11/2009 13:29, Chris Poppe a écrit :
> * 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.

This is a way of considering it.
My approach was rather :
* the unstructured value is mainly for humans
* the URI is mainly for machines

Since the "greatest common divisor" in all formats is plain text, we
have to flatten structured values as in MPEG7. For me, replacing a URI
(which is a kind of "pointer" to the FOAF structured value) is a similar
kind of "flattening".

> * 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.

Agreed, but then again, where do we stop? When underlying formats
differ, which one will we keep?
IMHO it is better to commit only to provide the unstructured value, the
metadata source, and the URI if available. Users may refer to the
original metadata if they need more detail.

Writing this, it occurs to me that the same argument applies to URIs...
One could always refer to the original metadata to figure out a URI if
available. But URI is just one extra field, while structured values may
be arbitrarily complex. And URIs are the fabric of the web, so my
intuition is that they deserve a special status in a web API.

> * 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").

I agree with that: identifiers in the underlying format may be non-URI.
I guess this should be made more explicit in the Ontology document, then.

> 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 :)

I see a URI as an *identifier* of some resource (a person, a company,
another document...) that *could* be dereferenceable if it follows the
linked data principle. If it is not, you can still get some information
about it by other means -- possibily inside the metadata source that
returned that URI.

So I would argue for using the "URI" field everytime a return value is
identified as a URI.

  pa