Fwd: Re: DC/ DCTerms and the Info Service Ontology

[Bob Ferris]

Hi,

I got an answer re. my Info Service Ontology request on the DCA mailing
list. I'm very happy about that ;)

Cheers,

Bob

-------- Original-Nachricht --------
Betreff: Re: DC/ DCTerms and the Info Service Ontology
Datum: Fri, 23 Jul 2010 18:54:12 +0100
Von: Pete Johnston <Pete.J...@EDUSERV.ORG.UK>
Antwort an: DCMI Architecture Forum <DC-ARCH...@JISCMAIL.AC.UK>
An: DC-ARCH...@JISCMAIL.AC.UK

Hi Bob,

> I'm currently designing the Info Service Ontology[7,8] - an ontology
> for
> linking resources to its information service, which could be then
> described more in detail, e.g. categorised or linked to quality ratings
> from information service quality rating agencies. With this ontology it
> should be possible to provide a basis, which, e.g. enable users the
> opportunity to choose their preferred information services as data
> sources for their knowledge base (or whatever) by selecting the
> different properties of such an information service.
>
> Therefore, I'm thinking currently much about the relation of the Info
> Service Ontology and DC/ DCTerms (I already create a sub property from
> dcterms:subject called is:main_subject). Here are my observations:
>
> 1. dc:publisher/ dcterms:publisher[1] - these properties are somehow
> related/ similar to is:info_service
>
> - description of dc:publisher/ dcterms:publisher: "An entity
> responsible
> for making the resource available."
> - dcterms:publisher has as range dcterms:Agent ("A resource that acts
> or
> has the power to act.")
>
> => currently, I would tend to mark is:info_service as sub property of
> dcterms:publisher

From the description of is:info_service here

http://infoserviceonto.sourceforge.net/is/spec/infoservice.html#info_service

I wasn't entirely sure whether it was always an "is made available by"
relationship, but if that is the case, the subproperty relation sounds good.

> 2. dcterms:Agent[2] - is somehow related/ similar to is:InfoService
>
> - description of dcterms:Agent: "A resource that acts or has the power
> to act."
>
> => currently, I would tend to mark is:InfoService as equivalent class
> or
> sub class of dcterms:Agent

The dcterms:Agent class is intentionally very broad, and I think it is
broader than the is:InfoService class. I think there are instances of
dcterms:Agent who wouldn't be instances of is:InfoService

http://infoserviceonto.sourceforge.net/is/spec/infoservice.html#InfoService

so a subclass relation sounds more appropriate than equivalentClass?

> 3. dc:type/ dcterms:type[3] - is somehow related/ similar to
> is:info_service_type
>
> - description of dc:type/ dcterms:type: "The nature or genre of the
> resource." + "Recommended best practice is to use a controlled
> vocabulary such as the DCMI Type Vocabulary [DCMITYPE]. To describe the
> file format, physical medium, or dimensions of the resource, use the
> Format element"
>
> - DCMI Type Vocabulary leads to types like e.g. dctypens:Service[4],
> which is also be somehow related/ similar to is:InfoService
>
> => currently, I would tend to mark is:info_service_type as sub property
> of dcterms:type

The dcterms:type property has rdfs:range of rdfs:Class.

If you say is:info_service_type is an rdfs:subPropertyOf dcterms:type,
then you end up saying (or allowing the inference) that values of the
property are classes (rdfs:Class).

As I understand it, at the moment that isn't the case, so I'm not sure
that's really what you want, but it may be OK.

> 4. dcterms:audience[5] - is also very interesting to propagate a
> specific audience for, which the information service is intended
>
> - description of dcterms:audience: "A class of entity for whom the
> resource is intended or useful."
>
> - this could may be used for the general information service
> description
> and also for specific information service quality ratings
>
> - it has the range of dcterms:AgentClass

.. so each value of dcterms:audience is an instance of dcterms:AgentClass.

And since dcterms:AgentClass is a subclass of rdfs:Class, each instance
of dcterms:AgentClass is also itself a class. (I think I got that right...)

> 5. dcterms:AgentClass[6] - as hook for audience classes/ groups/
> stereotypes
>
> - description of dcterms:AgentClass: "A group of agents." + "Examples
> of
> Agent Class include groups seen as classes, such as students, women,
> charities, lecturers."
>
> => is:InfoServiceType could also be seen as a dcterms:AgentClass (maybe
> a sub class of it)

So... (from above):

(i) an instance of is:InfoService is also an instance of dcterms:Agent.
(ii) a value of the is:info_service_type property is an instance of
rdfs:Class (as well as of the class is:InfoServiceType)

Then I think you are saying there are two possibilities:

(a) the class is:InfoServiceType is an instance of dcterms:AgentClass.
That doesn't say anything more about instances of is:InfoServiceType

(b) the class is:InfoServiceType is a subclass of dcterms:AgentClass. In
that case, instances of is:InfoServiceType are also instances of
dcterms:AgentClass and instances of rdfs:Class.

If (a), I'm not sure the class of service _types_ is an AgentClass (a
class of Agents)

If (b), then that would mean, for example:

- an individual is:InfoService (say, Facebook) would be a dcterms:Agent
- it would be related by the ls:info_service_type property to an
is:InfoServiceType of "social network services"
- that is:InfoServiceType of "social network services" would be a
rdfs:Class
- that is:InfoServiceType of "social network services" would be a
dcterms:AgentClass

I hope I got that right (but I might have missed something).

If so, yes, I think that would be consistent with DCMI's
intention/definition for AgentClass.

Pete

[zazi]

Hi Pete,
Hi all,

Thanks a lot for your insightful explanations.
I tried to resolve the DC/DCTerms alignment for the the Info Service
Ontology in the v0.7 branch[1,2]. More details below.

dcterms:publisher is now a super property of is:info_service. I also
extended the comment for a better description of the property.

>
>> 2. dcterms:Agent[2] - is somehow related/ similar to is:InfoService
>>
>> - description of dcterms:Agent: "A resource that acts or has the power
>> to act."
>>
>> => currently, I would tend to mark is:InfoService as equivalent class
>> or
>> sub class of dcterms:Agent
>
> The dcterms:Agent class is intentionally very broad, and I think it is broader than the is:InfoService class. I think there are instances of dcterms:Agent who wouldn't be instances of is:InfoService
>
> http://infoserviceonto.sourceforge.net/is/spec/infoservice.html#InfoService
>
> so a subclass relation sounds more appropriate than equivalentClass?

Well, that is still the question. I currently add dcterms:Agent as
super class of is:InfoService. You may have a look at the Information
Service definition[3] for a detailed description of this term. I see
an information service more as a facet of something.
I think, I feel fine with the super class setting.

>
>> 3. dc:type/ dcterms:type[3] - is somehow related/ similar to
>> is:info_service_type
>>
>> - description of dc:type/ dcterms:type: "The nature or genre of the
>> resource." + "Recommended best practice is to use a controlled
>> vocabulary such as the DCMI Type Vocabulary [DCMITYPE]. To describe the
>> file format, physical medium, or dimensions of the resource, use the
>> Format element"
>>
>> - DCMI Type Vocabulary leads to types like e.g. dctypens:Service[4],
>> which is also be somehow related/ similar to is:InfoService
>>
>> => currently, I would tend to mark is:info_service_type as sub property
>> of dcterms:type
>
> The dcterms:type property has rdfs:range of rdfs:Class.
>
> If you say is:info_service_type is an rdfs:subPropertyOf dcterms:type, then you end up saying (or allowing the inference) that values of the property are classes (rdfs:Class).
>
> As I understand it, at the moment that isn't the case, so I'm not sure that's really what you want, but it may be OK.

Well, I oversaw this range definition for some reason. I think, I
can't really do that, if I like to keep my ontology somehow OWL-DL
compatible, and I intend to have an OWL-DL ontology. I have the
feeling that I would mix up here the A-Box with the T-Box level (this
was also discussed in a thread about DC-FOAF alignment[5]). Currently,
the specific information service types are individuals, with this
inference I would move them up to the T-Box level, or?
I don't know, if you are aware of the "Dublin Core in OWL 2"
proposals[4] made by Simon Reinhardt. Currently, there is the range
for dcterms:type open. However, one could probably also define the
range as owl:Thing or a general dcterms:Type concept, which could
represent the general type for classification/categorization
statements.

I'll keep this alignment here open.

>
>> 4. dcterms:audience[5] - is also very interesting to propagate a
>> specific audience for, which the information service is intended
>>
>> - description of dcterms:audience: "A class of entity for whom the
>> resource is intended or useful."
>>
>> - this could may be used for the general information service
>> description
>> and also for specific information service quality ratings
>>
>> - it has the range of dcterms:AgentClass
>
> .. so each value of dcterms:audience is an instance of dcterms:AgentClass.
>
> And since dcterms:AgentClass is a subclass of rdfs:Class, each instance of dcterms:AgentClass is also itself a class. (I think I got that right...)
>

I think, it's more or less the same case with dcterms:audience here,
because dcterms:AgentClass is a sub class of rdfs:Class. In Simon
Reinhardt's proposal, dcterms:AgentClass is a owl:Class and has no
super class.

>> 5. dcterms:AgentClass[6] - as hook for audience classes/ groups/
>> stereotypes
>>
>> - description of dcterms:AgentClass: "A group of agents." + "Examples
>> of
>> Agent Class include groups seen as classes, such as students, women,
>> charities, lecturers."
>>
>> => is:InfoServiceType could also be seen as a dcterms:AgentClass (maybe
>> a sub class of it)
>
> So... (from above):
>
> (i) an instance of is:InfoService is also an instance of dcterms:Agent.

Yes.

> (ii) a value of the is:info_service_type property is an instance of rdfs:Class (as well as of the class is:InfoServiceType)

Hm, I think, that's not really good (as described above).

>
> Then I think you are saying there are two possibilities:
>
> (a) the class is:InfoServiceType is an instance of dcterms:AgentClass. That doesn't say anything more about instances of is:InfoServiceType
>
> (b) the class is:InfoServiceType is a subclass of dcterms:AgentClass. In that case, instances of is:InfoServiceType are also instances of dcterms:AgentClass and instances of rdfs:Class.
>
> If (a), I'm not sure the class of service _types_ is an AgentClass (a class of Agents)
>
> If (b), then that would mean, for example:
>
> - an individual is:InfoService (say, Facebook) would be a dcterms:Agent
> - it would be related by the ls:info_service_type property to an is:InfoServiceType of "social network services"
> - that is:InfoServiceType of "social network services" would be a rdfs:Class
> - that is:InfoServiceType of "social network services" would be a dcterms:AgentClass
>
> I hope I got that right (but I might have missed something).
>
> If so, yes, I think that would be consistent with DCMI's intention/definition for AgentClass.

Yes, however, as I mentioned above, I'm a bit unsure, whether this is
allowed or a good modelling in the OWL world. I'll like to keep these
things (is:InfoServiceContributorType, is:InfoServiceType) as
individuals (on the A-Box).

Cheers,


Bob

[1] http://infoserviceonto.svn.sourceforge.net/viewvc/infoserviceonto/infoservice/branches/infoserviceonto_v07/rdf/infoservice.n3
[2] http://infoserviceonto.svn.sourceforge.net/viewvc/infoserviceonto/infoservice/branches/infoserviceonto_v07/rdf/infoservice.owl
[3] http://infoserviceonto.wordpress.com/2010/06/23/what-is-an-information-service/
[4] http://bloody-byte.net/rdf/dc_owl2dl/index.html
[5] http://lists.foaf-project.org/pipermail/foaf-dev/2008-January/008817.html