W3C home > Mailing lists > Public > public-media-annotation@w3.org > April 2011

RE: EBUCore and Eurovision NewsML-G2 in RDF

From: Evain, Jean-Pierre <evain@ebu.ch>
Date: Tue, 5 Apr 2011 09:24:31 +0200
To: 'Pierre-Antoine Champin' <pierre-antoine.champin@liris.cnrs.fr>
CC: "public-media-annotation@w3.org" <public-media-annotation@w3.org>, "ecm@list.ebu.ch" <ecm@list.ebu.ch>
Message-ID: <7D1656F54141C042A1B2556AE5237D60010ED4977A00@GVAMAIL.gva.ebu.ch>
Hello Pierre-Antoine,

I followed the link... 

There is a lot to read beyond the initial page but if I focus on this page only, and on your comment,
I guess we can say it is about materialising inferences.  I agree that it is actually easier to get the
inferences being published and in my scenario the user is actually more an aggregator whose role is to collect data 
and publish it with all the inferences allowing to do what MAWG was aiming at, i.e. cross domain queries.

If I take the example of ma-ont and EBUCore:

I have the object property 'features' in ma-ont equivalent to the object property 'features' in ebucore.

However, the range in m-aont is 'person' while the range in ebucore is 'contact' knowing that the class 'person' is declared equivalent to 'contact' too.

If the aggregator has collected datasets in the ma-ont and ebucore formats and reindexed the data with the mapping schema, I am hoping that a SPARQL query in the form 'x features y' will e.g. for the same 'x' provide a list of 'y' made of persons and contacts (possibly overlapping, and / or complementary).

Discussion: However, if an aggregator collects data including inferences and e.g. based on the same RDF schema, these data sets will be coherent but it may also be true that some properties have been instantiated in a set that would allow to develop richer inferences when combined with another data set.  This is maybe when option 2 of my scenario has some sense?

Anyway, I'll keep following the thread of pages that you pointed me to. That looks very informative. But after NAB ;-)

Regards,

Jean-Pierre


-----Original Message-----
From: Pierre-Antoine Champin [mailto:pierre-antoine.champin@liris.cnrs.fr] 
Sent: lundi, 4. avril 2011 16:05
To: Evain, Jean-Pierre
Cc: public-media-annotation@w3.org; ecm@list.ebu.ch
Subject: Re: EBUCore and Eurovision NewsML-G2 in RDF

Hi Jean-Pierre

from the two options you present, it seems to me that your question
boils down to

 "should I materialize inferences or not?"

or in other terms

 "should I compute all the inference once and for all and store them?"

where option 1 is "yes" and option 2 is "no".

Some elements of answers can be found here

  http://patterns.dataincubator.org/book/ch04s07.html


-- and the short answer is "yes and no" :-)

 pa



On 04/04/2011 09:55 AM, Evain, Jean-Pierre wrote:
> Hello Pierre Antoine,
> 
> I'll try to go one step further in exploring the problem for which I
> don't have a clear answer (if there is to be one ;-).
> 
> Maybe the easiest is to go through scenarios:
> 
> Scenario 1: A user develops a green-field application and decides to
> use ma-ont. Descriptions / individuals are generated in this format
> using the RDF provided in the ontology and stored in a triple store
> (or else). The reasoned does the indexing following the schema.
> Searches can be made using e.g. SPARQL.
> 
> The same user realises that there is a lot of data conforming to one
> or more additional formats e.g EBUCore or NewsML-G2, both expressed
> in RDF. He starts harvesting the triples available in these formats
> and also wants to re-index this data from different sources. The user
> therefore acquires the schema and uses its reasoned to index the
> data.  This is primarily done on each set of data e.g. EBUCore and
> NewsML-G2 RDF, all results being agin stored e.g. in a triple store.
> 
> In order to combine this data and achieve richer query results. The
> user either develop its own RDF mapping between the different
> ontologies or reuses an existing one (like one of the files I
> distributed)......
> 
> This is where is the dilemma:
> 
> Option 1: he reindexes all the data in its triple store (containing
> ma-ont, EBUCore and NewsML-G2 triples) using only the mapping RDF
> schema provided separately.
> 
> Option 2: he creates a super schema importing ma-ont, EBUCore and
> NewsML-G2 in RDF, plus the mapping RDF schema and uses its reasoned
> to reindex all the data
> 
> Is option 1 better than or equivalent to option 2? Is there an
> another option? Etc.
> 
> Are there other scenarios that could allow addressing the problem
> more specifically ?
> 
> Best regards,
> 
> Jean-Pierre
> 
> 
> 
> 
> -----Original Message----- From: Pierre-Antoine Champin
> [mailto:pierre-antoine.champin@liris.cnrs.fr] Sent: samedi, 2. avril
> 2011 12:01 To: Evain, Jean-Pierre Cc: public-media-annotation@w3.org;
> ecm@list.ebu.ch Subject: Re: EBUCore and Eurovision NewsML-G2 in RDF
> 
> Hi Jean-Pierre,
> 
> On 03/30/2011 01:14 PM, Evain, Jean-Pierre wrote:
>> (...) These two ontologies offer maximum compatibility with MA-ONT
> 
> very nice :)
> 
>> I have done the exercise to define the equivalence between the 
>> classes and properties, which is really easy in the above 
>> circumstances.  However, I am facing a dilemma. Should I declare
>> the equivalences in a separate 'mapping ontology' pointing to the 
>> EBUCore, MA-ONT and NML-G2 ontologies as remote resources, or 
>> 'import' them within their own namespace in one ontology
>> containing the equivalence declarations?
> 
> not sure what you mean by "pointing to X as a remote resource", nor
> by "importint X in its own namespace"...
> 
> could you provide a short example of both approach?
> 
> pa
> 
> ----------------------------------------- 
> ************************************************** This email and any
> files transmitted with it are confidential and intended solely for
> the use of the individual or entity to whom they are addressed. If
> you have received this email in error, please notify the system
> manager. This footnote also confirms that this email message has been
> swept by the mailgateway 
> **************************************************

Received on Tuesday, 5 April 2011 07:25:06 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:17:41 UTC