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
