RE: about representing persons (and other things) in our ontology

Pierre Antoine, all,

Good summary of the situation but if we consider the current scope of MAWG which is to map between different metadata metadata representations, and as I tried to explain during the call. I cannot see how a URI/URL will point to e.g. a complex(type) description within an instance based on a structured schema like tva or mpeg7 personTypes or organisationTypes.  These instances might as a whole be seen a linked data via the uri/url of the file location but not chunks. Or are you proposing to have the Xpath added to the uri/url? Is this feasible? 

Furthermore, does this really make sense?  This would certainly lead to a degree of human intervention. Is it the purpose of our action?

If all the metadata to which we want to map were RDF, it would be simpler (also because complex structures wouldn't be expressed like in xml.  But this is not the case.

I think that what we want to do is to provide simple attributes and if data from complex structures have to be concatenated into something meaningful, then we have to define the method in the API.



-----Original Message-----
From: [] On Behalf Of Pierre-Antoine
Sent: mardi, 17. novembre 2009 15:23
Subject: about representing persons (and other things) in our ontology

Hi all,

I'm continuing that we started today during the teleconf.

Several ma: properties relate to complex objects, like persons and organizations for the fields ma:creator, ma:contributor...

As I see it, the in-scope format range from representing those object as opaque labels (e.g. ID3), to structured embeded data (e.g. TV-anytime ?), to a URI representing the object itself, relying on other formats to describe it (e.g. Media RDF).

This leads, in my view, to two consequences :

- our ontology should acknowledge the fact that *there is such thing* as an agent (person or organization), which is the range of ma:creator and ma:contributor, and that can descrived in a more or less structured way (from plain label to external linked data).

- our API should provide ways to reflect the different kinds of representations. My suggestion is to allow two representations :
 * a text label (which can be constructed by aggregating the fields
   of a structured representation, if any)
 * a URI (if one is provided by the underlying format, which may
   give access to a rich description according to the linked data

I don't think we should commit into any more structured description, which is bound to hinder interoperability.

On the other hand, I don't think we should give up the URI -- when it is provided, of course; I have no intent to *produce* linked data from legacy formats! But *if* linked data is available, we should give access to it. This is an API for the Web, and linked data is the *webbish* way of providing additional metadata. And finally, it *is* in the scope of the WG, since DC and Media RDF are.


Received on Wednesday, 18 November 2009 13:30:13 UTC