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.
Am 23.07.2010 19:54, schrieb Pete Johnston:
> 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.
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
|