> 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

> - 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

> - 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

> - 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

> - 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)

>> 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_...

> 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#InfoS...

> 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...)

>> - 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.

> 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.