Re: UDEF Representation in RDF

Hi–

We are looking at the use of SKOS to be the basis of mapping the UDEF to RDF, and Richard has suggested that the members of this list could supply expertise on SKOS which is perhaps lacking in our team at present. Thanks, Richard, for the suggestion! List members, I hope that you will be able to provide some input.

The UDEF -  see  - http://www.opengroup.org/udef/ is an information index based on ISO 11179. It has two hierarchies, one for object classes, and the other for properties. The UDEF tag for an element is  defined as  an object class tag concatenated with a property tag.

We are looking at an approach that would define UDEF object classes and UDEF properties as SKOS concepts, and use SKOS narrower/broader to capture the relation between a parent object class and its children, and between a parent property and its children.

The initial questions that we have are:
    - Does this look like a sensible approach?
    - Should we make the whole of the UDEF a single SKOS concept scheme, or would it be better 
      to have separate concept schemes for object classes and properties?

Input and advice from SKOS experts would be much appreciated!

Regards,
Chris
++++

Chris Harding
c.harding@opengroup.org



On 7 May 2012, at 15:18, <Richard.Parent@servicesquebec.gouv.qc.ca> <Richard.Parent@servicesquebec.gouv.qc.ca> wrote:

> Hi,
> 
> I do not believe it matters to put it in one or two SKOS concept schemes. I guess that both would be equivalent. 
> I am not an expert of SKOS, but I suspect that we often have a tendency to carry over to SKOS too much of the general RDF logic. But I don't know very much and I suggest that you make a consultation with the SKOS e-mail group at : 
> public-esw-thes@w3.org
> 
> Richard
> 
> -----Message d'origine-----
> De : 
> Envoyé : 4 mai 2012 04:34
> Cc : udef@opengroup.org
> Objet : Re: UDEF Representation in RDF
> 
> Hi, Richard-
> 
> Thanks for this! It was not sent to the UDEF list because you sent it from an address other than the one registered in our system, but members of the list will now be able to see what you have said in the copy below.
> 
> I believe that what you are saying is that we do not need to define special subclasses of the SKOS class of concepts. We can simply define root "UDEF object class" and "UDEF property" SKOS concepts, and we can use the SKOS narrows property to define the children of each UDEF node, and the SKOS narrowsTransitive property  to capture the UDEF subclass and sub-property relations.  I guess that's an advantage of this would be that software applications and tools that recognise the SKOS narrows and narrowsTransitive properties would then work on UDEF vocabularies, as well as making it easier to incorporate the UDEF definitions in the world of linked data.
> 
> We would still presumably distinguish the UDEF  by making it an SKOS concept scheme, with "UDEF object class" and "UDEF property" as top concepts. An alternative would be to have two SKOS concept schemes, one for UDEF object classes, and another for UDEF properties. This would make it clear that object classes and properties are different kinds of thing. Do you have any thoughts on this?
> 
> Regards,
> Chris
> ++++
> 
> Chris Harding
> c.harding@opengroup.org
> 
> 
> 
> On 3 May 2012, at 20:08, <Richard.Parent@servicesquebec.gouv.qc.ca> <Richard.Parent@servicesquebec.gouv.qc.ca> wrote:
> 
>> 
>> Hi,
>> 
>> I have produced a SKOS representation of a thesaurus. My understanding of the issue that you raise is that you carry too much of the rdf language when trying to distinguish between classes and properties within the SKOS format. UDEF classes and properties are both concepts in SKOS. UDEF is one scheme with two root nodes, one for the hierarchy of objects and one for the hierarchy of properties.
>> 
>> The logic that you used to carry in rdfs has to be represented outside of SKOS through the interface of the functions using it. So maybe do we still need rdfs for that purpose, for another reason that we could use SKOS. The usefulness of SKOS for UDEF is the doorstep to enter the house of the semantic web, more precisely of linked data. Linked data are the way of so-called web 3.0 to carry meaning : that is what UDEF is for, i.e. to carry meaning through a coding system of objects and properties. The vehicle to carry meaning is an intensive use of the Uniform Resource Identifier. Each code value of UDEF must be reachable through a distinct URI and that is what SKOS allows us to do, probably with the help of a SPARQL deployment for those triplets, and join the LOD cloud (LOD : Linked Object Data). Make a search with « LOD cloud » on Google.
>> 
>> The essential advantage of representing UDEF in the SKOS format is to make every code value adressable (dereferencable) from external resources, and inversely to reach external resources from any UDEF code value, be it a class or a property (all concepts). SKOS as a format uses a simplified rdf.
>> 
>> Richard Parent
>> Services Québec
>> Direction principale des services à la clientèle
>> 800 Place d'Youville, 17e
>> Québec. (Québec) G1R 3P4
>> Téléphone : 418 646-0732
>> Télécopieur : 418 646-3953
>> richard.parent@servicesquebec.gouv.qc.ca
>> www.servicesquebec.gouv.qc.ca
>> 
>> -----Message d'origine-----
>> De :
>> Envoyé : 3 mai 2012 13:21
>> Objet : UDEF Representation in RDF
>> 
>> Hi -
>> 
>> In the UDEF open meeting in Cannes last week, it was recommended that we revise the way that the UDEF is represented in RDF, and that in particular we should look at aligning it with SKOS. Here is an outline proposal for representing the UDEF in RDF in a way that is compatible with SKOS. It is put forward for discussion. Please comment on it, to the udef list.
>> 
>> The current RDF representation was defined some years ago, before SKOS was developed. It uses the RDFS subclass concept to capture the UDEF concepts of subclass and subproperty. This may be convenient, but it is not ideal.
>> 
>> UDEF properties are clearly properties rather than classes, so that using the subproperty concept of RDFS might seem appropriate for UDEF properties, while keeping RDFS subclass for UDEF classes. But in fact the UDEF object classes are not classes in the RDF sense. UDEF tagging is done relative to an enterprise. Employee.Person, for example, refers to an employee of the enterprise in question. Strictly speaking, I believe that the UDEF object classes should be defined as the ranges of properties whose domains are the set of enterprises.
>> 
>> The Simple Knowledge Organization System (SKOS) defined by the W3C (see http://www.w3.org/TR/2009/REC-skos-reference-20090818/) is a way of representing knowledge organization systems, such as thesauri, taxonomies, classification schemes and subject heading systems, in RDF. The UDEF is a classification scheme, and it therefore looks as though it could be appropriate to use SKOS to represent it.
>> 
>> SKOS identifies and labels concepts, rather than classes or properties. The definition of concept is very loose, and can cover UDEF object classes and UDEF properties without too much discomfort. "A SKOS concept can be viewed as an idea or notion; a unit of thought. However, what constitutes a unit of thought is subjective, and this definition is meant to be suggestive, rather than restrictive."
>> 
>> It is important for the UDEF that object classes and properties are distinguished. We cannot therefore simply refer to both object classes and properties as SKOS concepts.
>> 
>> Here is a proposal that takes these considerations into account.
>> 
>> 1. We define classes "UDEF Object Class" and "UDEF Property" as subclasses of the SKOS class of concepts.
>> 
>> 2. We define relations "child class of" and "child property of" on these classes, respectively. We assert that these are sub-properties of the SKOS "narrower" property.
>> 
>> 3. We further define relations "subclass of" as the transitive closure of "child class of" and "sub property of" as the transitive closure of "child property of". We assert that these are sub-properties of the SKOS narrowerTransitive property.
>> 
>> This is just a starting point. There is more work to be done on labels and descriptions. But let's not go too far into the refinements of the proposal, before its basic principles are agreed. Please comment on the starting point now. We can then discuss refinements or changes next week.
>> 
>> Regards,
>> Chris
>> ++++
>> 
>> Chris Harding
>> c.harding@opengroup.org
>> 
>> 
>> 
>> 
>> ________________________________
>> Ce message est confidentiel et est à l'usage exclusif du destinataire identifié ci-dessus. Toute autre personne est, par les présentes, avisée qu'il lui est strictement interdit de le diffuser, de le distribuer, d'en dévoiler le contenu ou de le reproduire. Si vous avez reçu cette communication par erreur, veuillez en informer l'expéditeur par courrier électronique immédiatement et détruire l'original de ce message ainsi que toute copie.
>> ________________________________
>> 
> 
>

Received on Tuesday, 8 May 2012 09:04:45 UTC