Re: [ANN] LOD from Italian National Research Council

On 2/9/11 12:57 PM, Enrico Daga wrote:
> Dear Hugh, Kingsley, all,
>
> thank you both for your hints.
>
>>> Where the dataset owner agrees that, for example, dct:creator aligns with
>>> pubblicazioni:autore, then perhaps you can.
>>> Of course, there is a question about why dct:creator was not used in the
>>> first place, but it can be neat to simply use all your own properties, so
>>> that's OK.
>>> But if the alignment is to go in the dataset, it should be part of the
>>> knowledge capture process, not added by a third party.
> In our case we are the maintainer of the dataset and ontology so we
> know that a triple like
>
> pubblicazioni:autore rdfs:subClassOf dct:creator
>
> is correct.

Yes, but "correct" is one of those subjective things when working at 
InterWeb scale. Thus, its important that you partition your data using 
Named Graphs rather than work with a single graph.

The approach above allows you to see things as you seek, while letting 
others do the same via their specific "context lenses".

> Our point is mainly related to make the dataset easily reusable by the
> means of shared vocabularies even if those commonly known names have
> not been used in the process of dataset generation.

Yes, but if you have the vocabulary triples (TBox) in a separate name 
graph you're fine. Or you can leave everything in your main graph, but 
place any inter vocabulary mapping triples in a separate Named Graph.

> We want our data to be self-explained providing suggested alignments
> between our internal vocabulary and public ones, at least for very
> common cases, such "abstract:Titolo" and "dc:title", for example.

Yes, this is all clear. The key is to partition your data, there's no 
downside bar deflection of barbs from those who see things differently 
due to their specific "context lenses" when dealing with your data.

>>> So if a consumer of the data wanted to assert
>>> cnr:coauthor rdfs:subPropertyOf foaf:knows
>>> that is up to them and would be fine, but to enforce it seems not good to
>>> me.
> Yes, in this case the alignment implies additional assumptions, but in
> principle we need this (maybe not exactly that...) to describe the
> dataset to non-cnr people.

Again, that's fine, put the triples in a separate Named Graph. It won't 
adversely affect anything.

>> In a nutshell, put the controversial stuff in its own Named Graph within
>> your Virtuoso instance. When making Linked Data Resources (e.g. HTML browser
>> pages) you can scope your SPARQL DESCRIBES or CONSTRUCTs to the main Graph
>> (the one without an alignment triples etc..). The SPARQL endpoint stays as
>> the open ended access point to all data.
> So you suggest to use a separate graph, not involved in content
> negotiation but accessible through the sparql endpoint.

I mean:

1. Your HTML pages (which use content negotiation and SPARQL DESCRIBE or 
CONSTRUCTS) to make Description Page can be scoped to the entire quad 
store or specific Named Graphs

2. SPARQL endpoint is always open for people to query the entire 
collection of graphs or specific Named Graph combos.

You have to decide how you want to project your world view to the 
public. Bottom line, the public always has a SPARQL endpoint to they can 
apply their specific "context lenses" assuming you choose to have you 
world view (including cross vocabulary mappings) exposed in your Linked 
Data pages.

> This solution could be good, but brings more/new questions.
> Let's say we create a new dataset<http://data.cnr.it/alignments>,
> what should it return?
> 1) alignments at the schema level between the CNR ontology and public
> well-known vocabularies, triples like "pubblicazioni:autore
> rdfs:subClassOf dct:creator"
> 2) the above plus materialized triples, for example:
>
>>>> cnrdata:AldoGangemi foaf:knows cnrdata:EnricoDaga
>>>> cnrdata:AldoGangemi rdf:type foaf:Person
> The first would leave the interpretation of the alignment to the
> client application, the second would duplicate knowledge, leading to
> maintainability issues (at least in the long term).

Remember, when using Virtuoso you can conditionally apply inference 
rules via SPARQL, so your alignment triples become conditional and 
matrialize for query evaluation purposes only, when you leverage this 
aspect of Virtuoso. You don't have to fully materialize these triples.

> Another point is, if we choose solution (1) (only vocabulary
> alignments and no data)
> - how we formally (where and with which vocabulary) connect the
> dataset to its alignment?
> - how machines would learn that my vocabulary, in some part, could be
> interpreted as a variation of a more common set of terms?

You can make all kinds of Linked Data description pages re. Virtuoso, 
maybe take a look at this Linked Data Deployment in 3 steps guide [1] to 
get a feel for how simple this has become.

Links:

1. 
http://www.openlinksw.com/dataspace/kidehen@openlinksw.com/weblog/kidehen@openlinksw.com%27s%20BLOG%20%5B127%5D/1642 
-- how to simply load data into Virtuoso and start using Linked Data 
pages without hassles. Makes my comments clearer once you play around at 
bit.

Kingsley
> Bests
>
> Enrico
>
> On 9 February 2011 16:12, Kingsley Idehen<kidehen@openlinksw.com>  wrote:
>> On 2/9/11 8:33 AM, Hugh Glaser wrote:
>>> Hi Aldo,
>>> Nice stuff.
>>> Regarding vocabulary alignment.
>>> I would suggest you might want to keep it out of your dataset.
>>> Vocabulary alignment is a matter of opinion; of course your dataset is
>>> opinion as well, but it is the opinion of the organisation, whereas the
>>> vocabulary alignment you talk about might be somebody else's opinion.
>>> Where the dataset owner agrees that, for example, dct:creator aligns with
>>> pubblicazioni:autore, then perhaps you can.
>>> Of course, there is a question about why dct:creator was not used in the
>>> first place, but it can be neat to simply use all your own properties, so
>>> that's OK.
>>> But if the alignment is to go in the dataset, it should be part of the
>>> knowledge capture process, not added by a third party.
>>>
>>> In fact, the example you choose is great.
>>> It is not at all clear to me that
>>> cnr:coauthor rdfs:subPropertyOf foaf:knows
>>> is actually what an organisation would want to say.
>>> Even with the loosest meaning of foaf:knows, there will be co-authors who
>>> do not foaf:knows each other (certainly in some fields).
>>> And some people would be upset that their organisation was publishing data
>>> stating that they did.
>>> (I just checked the latest edition of Nature, and the two articles each
>>> have upwards of 50 authors from all over the world; I'm sure many of them
>>> have never communicated with each other, apart from this article.)
>>> One of the advantages of using your own ontology is that you are never
>>> saying anything other than what you meant (whatever that might be :-) )
>>>
>>> So if a consumer of the data wanted to assert
>>> cnr:coauthor rdfs:subPropertyOf foaf:knows
>>> that is up to them and would be fine, but to enforce it seems not good to
>>> me.
>>>
>>> And to help them you might provide a separate document with the alignments
>>> in them, so that they can pick them up if they want.
>>> And our policy is to do exactly the same with the identity management
>>> thing as well, which is actually a similar problem (and I would be happy to
>>> discuss how to do that with you, but I think we would need to go off-list
>>> for that, as we have had many discussions on the list about it ;-) )
>>>
>>> I know I haven't tackled the technical issues much, which is what you are
>>> asking, but I always start at the socio :-)
>> Aldo and colleagues,
>>
>> Congrats re. your project!
>>
>> In a nutshell, put the controversial stuff in its own Named Graph within
>> your Virtuoso instance. When making Linked Data Resources (e.g. HTML browser
>> pages) you can scope your SPARQL DESCRIBES or CONSTRUCTs to the main Graph
>> (the one without an alignment triples etc..). The SPARQL endpoint stays as
>> the open ended access point to all data.
>>
>> This area can get artificially confusing since DBMS architectures differ re.
>> SPARQL databases that support RDF resource import and query access. I
>> embarked on a somewhat similar exercise with @danbri last week re. DBpedia
>> and Open Archives Movies. In this case it wasn't about alignments per se.,
>> but the fundamental principles re. partitioning and scope control are
>> ultimately the same.
>>
>> Links:
>>
>> 1. http://danbri.org/words/2011/02/01/658 -- post by Danbri about the
>> exercise
>> 2. http://kingsley.idehen.net/c/GOK2B -- actual PivotViewer page (click on
>> "edit" to see the SPARQL behind and note how DBpedia and Danbri's Graphs are
>> joined)
>>
>> Kingsley
>>> Best
>>> Hugh
>>>
>>> On 9 Feb 2011, at 09:58, Aldo Gangemi wrote:
>>>
>>>> Dear all, we are happy to announce the release of the beta version of
>>>> data.cnr.it and the Semantic Scout exploratory browser.
>>>>
>>>> data.cnr.it [1] is the linked open data version of the scientific data
>>>> from the Italian National Research Council, and it includes researchers,
>>>> institutes, research programmes, publications, topics, etc.
>>>> A Virtuoso-powered SPARQL endpoint is available at [4]; a top-down
>>>> browser is available at [5]; a voiD description is at [6].
>>>>
>>>> The Semantic Scout [2] is an experimental exploratory browser applied to
>>>> the data.cnr.it datasets, cf. a paper published at EKAW2010 [3] for details.
>>>>
>>>> data.cnr.it and the Semantic Scout have been designed by the Semantic
>>>> Technology Lab ([7], see [8] for credits) that comprises semantic web
>>>> researchers and engineers from ISTC-CNR (the Institute of Cognitive Sciences
>>>> and Technologies of the Italian National Research Council), and from the
>>>> Information Systems Unit of the Italian National Research Council.
>>>>
>>>> We have used linked data principles, and the datasets are based on
>>>> modular, pattern-based designed OWL ontologies [9]. Data have been
>>>> triplified from multiple CNR databases, and enriched by means of OWL
>>>> reasoning (ABox materialization and classification), as well as by NLP and
>>>> graph mining techniques, e.g. the topics for the researchers have been
>>>> learnt by an automatic categorization system that uses researchers' textual
>>>> signatures (textual records) against the textual signature (pages) of
>>>> DBpedia categories.
>>>>
>>>> Current work is on integrating a more robust identity management and its
>>>> possible integration with Okkam, a deeper voiD description of the datasets,
>>>> entity linking to other LOD datasets (e.g. DBLP), more vocabulary alignment
>>>> (currently limited to FOAF, SKOS, and DC), etc.
>>>>
>>>> Regarding the last point, we are discussing the problem if vocabulary
>>>> alignment should be reflected or not in the datasets by means of
>>>> materialization. This problem has pervasive consequences on the size of the
>>>> services vs. datasets that enable linked data consumption: any help from the
>>>> community about pros and cons of either approaches? For example, if we
>>>> declare (schema level):
>>>>
>>>> cnr:coauthor rdfs:subPropertyOf foaf:knows
>>>> cnr:Researcher rdfs:subClassOf foaf:Person
>>>>
>>>> and we have e.g. in the data (*simplified names*):
>>>>
>>>> cnrdata:AldoGangemi cnr:coauthor cnrdata:EnricoDaga
>>>> cnrdata:AldoGangemi rdf:type cnr:Researcher
>>>>
>>>> should we materialize an additional dataset containing e.g.:
>>>>
>>>> cnrdata:AldoGangemi foaf:knows cnrdata:EnricoDaga
>>>> cnrdata:AldoGangemi rdf:type foaf:Person
>>>>
>>>> or should that be provided by a SPARQL endpoint under some entailment
>>>> regime?
>>>>
>>>> Consider that this is not only a matter of SPARQL efficiency vs. amount
>>>> of data, but also of data entanglement: e.g. when materialized, the topology
>>>> of linked datasets would be severely complicated by the mutityping of
>>>> individuals.
>>>>
>>>> Thanks for any advise (there not seems to be any best practice yet)
>>>> Ciao
>>>> Aldo, Enrico, Alberto
>>>>
>>>> [1] http://data.cnr.it
>>>> [2] http://bit/ly/semanticscout
>>>> [3] http://data.cnr.it/site/resources
>>>> [4] http://data.cnr.it/sparql/
>>>> [5] http://data.cnr.it/data/cnr/individuo/CNR
>>>> [6] http://data.cnr.it/data/http://data.cnr.it/dataset/
>>>> [7] http://stlab.istc.cnr.it
>>>> [8] http://data.cnr.it/site/contacts
>>>> [9] http://data.cnr.it/site/ontology
>>>>
>>>>
>>>> _____________________________________
>>>>
>>>> Aldo Gangemi
>>>> Senior Researcher
>>>> Semantic Technology Lab (STLab)
>>>> Institute for Cognitive Science and Technology,
>>>> National Research Council (ISTC-CNR)
>>>> Via Nomentana 56, 00161, Roma, Italy
>>>> Tel: +390644161535
>>>> Fax: +390644161513
>>>> aldo.gangemi@cnr.it
>>>> http://www.stlab.istc.cnr.it
>>>> http://www.istc.cnr.it/createhtml.php?nbr=71
>>>> skype aldogangemi
>>>> okkam ID: http://www.okkam.org/entity/ok200707031186131660596
>>>>
>>
>> --
>>
>> Regards,
>>
>> Kingsley Idehen
>> President&    CEO
>> OpenLink Software
>> Web: http://www.openlinksw.com
>> Weblog: http://www.openlinksw.com/blog/~kidehen
>> Twitter/Identi.ca: kidehen
>>
>>
>>
>>
>>
>>
>>
>
>


-- 

Regards,

Kingsley Idehen 
President&  CEO
OpenLink Software
Web: http://www.openlinksw.com
Weblog: http://www.openlinksw.com/blog/~kidehen
Twitter/Identi.ca: kidehen

Received on Wednesday, 9 February 2011 18:18:29 UTC