Fwd: Re: void:Dataset ontology concept linking

Skip to first unread message

Bob Ferris

Dec 16, 2010, 1:41:40 PM12/16/10
to info-service-ontolog...@googlegroups.com

the voiD developers published a revised draft of the voiD Vocabulary on
w3.org (see [1]). So I thought that it might be useful to suggest to
include a description of the relationship between both vocabularies in
their specific specification documentations. The email I sent to the
voiD developers is attached below that follows by a discussion from
October 2010 with Richard Cyganiak about the voiD Vocabulary / Info
Service Ontology relationship.

An comments on that are welcome.



PS: I created also a ticket on the voiD issues tracker (see [2])

[1] http://www.w3.org/2001/sw/interest/void/



at the beginning, congrats to the revised published voiD draft on w3.org.

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 that can describe also Linked Data
information services (e.g. DBPedia see [1]), and the other way around,
that some datasets are also information services.



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

Am 06.10.2010 13:21, schrieb Bob Ferris:
> Am 06.10.2010 12:39, schrieb Richard Cyganiak:
>> On 6 Oct 2010, at 08:34, Bob Ferris wrote:
>>> Okay, that means that "dataset is accessible on the Web" is now an
>>> optional part and a dataset do not always act as an web information
>>> service.
>>> So void:Dataset can't really act always as a sub class of
>>> is:InfoService. However, the "abstract collections of triples without
>>> associated access mechanism" are data dumps, or?
>> No -- data dumps *are* an access mechanism to a void:Dataset.
>> An example:
>> <#MyDS> a void:Dataset;
>> void:sparqlEndpint </sparql>;
>> void:subset [
>> a void:Linkset;
>> rdfs:comment "Links between geographical locations
>> in MyDS and DBpedia, generated using Silk";
>> void:target <#MyDS>;
>> void:target <#DBpedia>;
>> void:triples 1532;
>> ];
>> .
>> This states that there is a dataset �MyDS� accessible via a SPARQL
>> endpoint, and it has a subset which is a linkset consisting of 1532
>> links between MyDS as DBpedia.
>> The class of linksets is defined as a subclass of dataset.
>> So, the linkset described above is a dataset without access mechanism.
>> It can be accessed as a *part* of the bigger MyDS dataset through that
>> dataset's SPARQL endpoint. But calling the linkset an information
>> service seems misleading.
>> Hope that clarifies.
> Agreed ;)
> Thanks a lot for clarification. Although, one can also argue in the
> described use case, since the linkset is a subset of a bigger dataset,
> it also inherits its features and hence its information service
> capabilities. Nevertheless, I think its okay as it is currently, because
> this is only one use case of linksets.
> Cheers,
> Bob

Am 05.10.2010 21:18, schrieb Richard Cyganiak:
> Hi Bob,
> A blast from the past -- I missed this email in the torrent the first
> time round, and just discovered it while clearing out a metaphorical
> dusty pile in the attic.
> Not sure if you're aware of this, but the draft of the upcoming version
> 2 of voiD [1] has a slightly different, hopefully more precise
> definition of void:Dataset:
> �A dataset is a set of RDF triples that are published, maintained or
> aggregated by a single provider. Unlike RDF graphs, which are purely
> mathematical constructs [RDF Concepts], the term dataset has a social
> dimension: We think of a dataset as a meaningful collection of triples,
> that deal with a certain topic, originate from a certain source or
> process, are hosted on a certain server, or are aggregated by a certain
> custodian. Also, typically a dataset is accessible on the Web, for
> example through resolvable HTTP URIs or through a SPARQL endpoint, and
> it contains sufficiently many triples that there is benefit in providing
> a concise summary.�
> My take on the relationship to is:InfoService is that at least *some*
> datasets definitely are *not* instances of is:InfoService, namely those
> that are just abstract collections of triples without associated access
> mechanism.
> On the other hand, some is:InfoServices also clearly aren't datasets,
> because they could may make all sort of other stuff besides RDF triples
> available.
> So there's no subclass relationship either way.
> You could argue that there is some overlap between the classes (some
> entities may be members of both), but I don't feel quite comfortable
> taking a stance on that question. I wouldn't object to someone stating
> that their entity is both a void:Dataset and an is:InfoService.
> Best,
> Richard
> [1] http://void-impl.googlecode.com/svn/trunk/guide2/index.html
> On 25 Jun 2010, at 21:02, Bob Ferris wrote:
>> Hi everybody,
>> I'm currently developing the Info Service Ontology [1,2,3,4], which
>> enables an association of arbitrary resources to its underlying
>> information service (see [5] for a definition of the term 'information
>> service').
>> Furthermore, such an information service could then be described,
>> categorized and rated (re. its information service quality) through
>> the is:InfoService concept[2] and its relations to more detailed
>> description concepts (see [3] for a proof-of-concept example).
>> As it becomes more and more important for data/knowledge consumer to
>> (maybe automatically) select the right/a good information service,
>> which delivers this information, an information service quality rating
>> could probably deliver information, which will hopefully help the
>> data/knowledge consumer to find a good choice.
>> These information service quality ratings could be done by several
>> information service quality rating agencies for different information
>> services (also based on maybe different Info Service Quality Ontology
>> specifications, e.g. [7] as an interesting information quality
>> classification).
>> Now to the important part, why I'm contacting your list ;)
>> How do you think about the relation of
>> void:Dataset ("A dataset is a collection of data, published and
>> maintained by a single provider, available as RDF, and accessible, for
>> example, through dereferenceable HTTP URIs or a SPARQL endpoint.")
>> to
>> is:InfoService ("An Information Service is this part of an Information
>> System that serves data/knowledge/information to customers and
>> collects it from its contributors, to manage and store it by
>> optionally using administrators.").
>> I figured out void:Dataset as a concept, which should also be covered
>> by the definition of is:InfoService (information service). However,
>> the definition of void:Dataset is a bit more restrictive re. its
>> scope, so I think void:Dataset should be a sub concept of
>> As already mentioned on the Info Service Ontology mailing list[6],
>> there are (more or less, so far as I know) two ways for defining the
>> association/relation between the concepts void:Dataset and
>> is:InfoService:
>> 1. :my_instance_of_something a void:Dataset , is:InfoService . # the
>> association is then only on the A-Box level
>> 2. void:Dataset rdfs:subClassOf is:InfoService . # this expresses a
>> bit stronger that void:Dataset is a part of is:InfoService
>> How do you think about building this relation?
>> In general, it might be enough to define a 'best practice' re.
>> suggesting association case '1.' for typing instances with a
>> is:InfoService association. However, I think building a stronger
>> relation might be better for reasoning options (following the
>> principle: tell the (dumb) machine as many as you know) and also a bit
>> easier in defining individuals.
>> So, please let me know, how you would create this ontology concept
>> relation.
>> Thank you for all your (forthcoming) efforts.
>> Cheers,
>> Bob
>> [1]

>> [2]

>> [3]

>> [4] https://infoserviceonto.wordpress.com/
>> [5]

>> [6]

>> [7] http://w3.cyu.edu.tw/ccwei/PAPER/ERP/data%20quality%28JMIS%29.pdf
>> --
>> You received this message because you are subscribed to the Google
>> Groups "void-internal" group.
>> To post to this group, send email to
>> void-rdfs...@googlegroups.com.
>> To unsubscribe from this group, send email to
>> void-rdfs-inter...@googlegroups.com.
>> For more options, visit this group at
>> http://groups.google.com/group/void-rdfs-internals?hl=en.

Reply all
Reply to author
0 new messages