Relationship to the Info Service Ontology

[GoogleCodeExporter]

I would suggest that we should mention or vocabularies in the specific 
specification documentations and describe their relationship to each other, 
i.e. the Info Service Ontology[1] that can describe also Linked Data 
information services (e.g. DBPedia see [2]), and the other way around, that 
some datasets are also information services.

[1] http://purl.org/ontology/is/core#
[2] http://purl.org/ontology/is/inst/

Original issue reported on code.google.com by zazi0...@googlemail.com on 16 Dec 2010 at 6:24

[GoogleCodeExporter]

This is not a defect. Unsure how/if we should do this. Who is behind the 'Info 
Service Ontology'? What are the use cases, implementations, etc?

Original comment by Michael.Hausenblas on 16 Dec 2010 at 6:30

• Added labels: Priority-Low, Type-Enhancement
• Removed labels: Priority-Medium, Type-Defect

[GoogleCodeExporter]

> This is not a defect.

sorry for that, I've overseen this issue

> Unsure how/if we should do this.

There should be an email thread in your mailing list with the title " 
void:Dataset ontology concept linking". Richard Cyganiak clarified there that 
there is sub class or equivalent class relationship between void:Dataset and 
is:InfoService. However, that there are cases where it can be both. 
The property is:info_service, which has as range the concept is:InfoService, is 
now a sub property of dcterms:publisher, since I aligned the Info Service 
Ontology to DC/DCTerms. Because of that one can now add an is:InfoService 
instance as a publisher of a dataset, since you suggested to use 
dcterms:publisher to associate a publisher to a dataset description.

> Who is behind the 'Info Service Ontology'? 

Currently, that's more or less only me* who is behind the Info Service Ontology 
specification. Although, there exist a mailing list for comments and feedback 
and everyone is invited to contribute to this ontology specification.
I developed this ontology as part of my diploma thesis project. 

> use cases

1. information service description & information service quality descriptions

The initial intention behind designing this ontology was to add some knowledge 
re. linked websites from different information services, e.g. Wikipedia or 
MusicBrainz, in semantic graphs. 
Information service descriptions and/or information service quality 
descriptions can be provided by different information service rating agencies. 
This condition can assists the user to select information services on the basis 
of information service descriptions provided by information service rating 
agencies he/she trusts.

2. information service choice

The user should have the possibility to preselect information services of 
his/her choice on the basis of information service descriptions and information 
service quality ratings. 
There are two auxiliary opportunities, which can alleviate this task. As a 
result of selected stereotype instances of different stereotype categories or a 
complete analysis of the personal music collection of a user, the knowledge 
management system can suggest (semi-automatic) or set (automatic) specific 
appropriated information
services as a foundation for the information federation task of knowledge 
requests.
Furthermore, the knowledge management system should consider, whether some 
information services are better qualified for a specific knowledge request, or 
whether other information services can be excluded there a priori on the basis 
of the preselected information services of the user and the characteristics of 
these information services.
This should enable an a priori reduction of the overall information space, 
which can be considered in general, and/or an optimization regarding specific 
knowledge requests, for instance by processing a query specific ranked list of 
source information services.

> implementations

tbc :\

*) there are some members on the mailing list ;) 

Original comment by zazi0...@googlemail.com on 16 Dec 2010 at 7:19

[GoogleCodeExporter]

There are many vocabulary terms that voiD terms are conceptually related to, 
lots of which are widely implemented, that we don't detail in the voiD 
documentation. To try to do this would detract from the clarity and focus of 
the documentation. I vote Won'tFix (for now at least).

Original comment by K.J.W.Al...@gmail.com on 17 Dec 2010 at 8:14

[GoogleCodeExporter]

We resolved in today's editors' call to close this issue as WontFix. The Info 
Service Ontology at this point is a proposal that has not yet seen significant 
implementation and adoption. From this point of view, it is not clear how voiD 
would be improved by pointing to it.

Original comment by richard....@gmail.com on 20 Jan 2011 at 12:06

• Changed state: WontFix

[GoogleCodeExporter]

Okay, I thought it as a good chance to push forward the support for existing 
information services (as the most important source for void:Datasets) and to 
aid one another (work together!).

Original comment by zazi0...@googlemail.com on 20 Jan 2011 at 12:17

[GoogleCodeExporter]

Marking as “SWIG feedback”

Original comment by richard....@gmail.com on 3 Feb 2011 at 4:15

• Added labels: SWIG-feedback