Hi Thomas,
(I apologise if this goes over material you already know, but you said
you were new to using RDF and SKOS.)
The starting point for designing your solution is to understand that
SKOS merely specifies particular semantics for creating an RDF document.
Any assertion that is valid in an RDF document is also valid in SKOS.
Whether rdf:parseType is appropriate depends upon the context of the
XML. Remember that all RDF consists of a set of triples in the form:
subject, predicate, object
A basic SKOS concept in RDF/XML looks something like this:
<skos:Concept rdf:about="http://ex.com/concepts#animals">
<skos:prefLabel>animals</skos:prefLabel>
<skos:altLabel>creatures</skos:altLabel>
<skos:altLabel>fauna</skos:altLabel>
</skos:Concept>
which is a way of making the following assertions:
<http://ex.com/concepts#animals> rdf:type skos:Concept.
<http://ex.com/concepts#animals> skos:prefLabel animals.
<http://ex.com/concepts#animals> skos:altLabel creatures.
<http://ex.com/concepts#animals> skos:altLabel fauna.
A good way to read these is to add the words "has" and "of", ie
"concepts#animals has skos:altLabel of creatures".
Here's the important and somewhat confusing thing about RDF/XML -- you
cannot add XML which breaks the subject-predicate-object hierarchy
unless you specifically denote it using rdf:parseType="Literal".
For example, this is not valid RDF/XML:
<skos:Concept rdf:about="http://ex.com/professor#smithj">
<skos:prefLabel>Smith, John</skos:prefLabel>
<my:address>
<my:addr1>Unit 12</my:addr1>
<my:addr2>194 London Circuit</my:addr2>
</my:address>
</skos:Concept>
The reason this breaks is that we don't have an object to point
"my:address" at. The two possible object targets of any predicate are a
literal (string or XML) or another RDF resource.
Instead, write the RDF/XML like this:
<skos:Concept rdf:about="http://ex.com/professor#smithj">
<skos:prefLabel>Smith, John</skos:prefLabel>
<my:address xmlns:xal="urn:oasis:names:tc:ciq:xsdschema:xAL:2.0"
rdf:parseType="Literal">
<xal:AddressDetails>
<xal:AddressLines>
<xal:AddressLine>Unit 12</xal:AddressLine>
<xal:AddressLine>194 London Circuit</xal:AddressLine>
</xal:AddressLines>
</xal:AddressDetails>
</my:address>
</skos:Concept>
This informs any RDF parser that the object pointed to by my:address is
an XML literal, and should be parsed as such.
*If* you already have an existing medical XML vocabulary, the quickest
way to add this to a SKOS document would be to add a single custom RDF
predicate with rdf:parseType="Literal", and then to insert the XML
fragment you need from the medical vocabulary here under this.
On the other hand, if you are newly constructing this medical vocabulary
now, you could simply write your vocabulary spec in a way that is
RDF/XML compliant, for example:
<skos:Concept rdf:about="http://ex.com/professor#smithj">
<skos:prefLabel>Smith, John</skos:prefLabel>
<myns:ATCID>123</myns:ATCID>
<myns:attr1>abc</myns:attr1>
<myns:attr2>xyz</myns:attr2>
</skos:Concept>
In the absence of more detailed information, it's hard to give more
specific advice, but I hope this provides you with some pointers.
Cheers,
-- Stephen.
Thomas Bassetto wrote:
> Hello,
>
> I want to create a Web Service for a medical database. The response
> from the Web Service should be a valid SKOS document (inside a SOAP
> envelope). Hopefully a lot of SKOS elements match my needs. However,
> there are some additional information without specific SKOS element
> available.
>
> According to http://www.w3.org/TR/skos-primer/#secskosspecialization ,
> "Users can create their own properties and classes and attach them to
> the standard SKOS vocabulary elements by using the rdfs:subPropertyOf
> and rdfs:subClassOf properties from the RDF Schema vocabulary".
>
> I plan to create an element for each additional information (like
> <myns:ATCID/>)[1] for defining a specific ID.
>
> But the client doesn't agree. He thinks that this solution is
> "proprietary" since I create new elements which are not described in
> the norm.
>
> He propose two alternate solutions :
> * use rdf:parseType as attribute to existing SKOS element. To be
> frank, I can't see how it could be a solution.
> * create a new attribute to <skos:Concept/> ant put ALL the additional
> information into it, separated by a coma. Example : <skos:Concept
> rdf:about="http://site.fake#diagnostic"
> myns:annotation="ADDINF1=value1,ADDINF2=value2,ADDINF3=value3,...">
>
> What do you think ? I believe that specialising SKOS elements remains
> the best solution.
> Moreover, I'm wondering if it's really possible to create a new
> attribute for <skos:Concept/>. How ? I'm have never used RDF and SKOS
> before.
>
> Finally, I have another question. I want to use JENA[2] in order to
> generate a Java file to create a SKOS document. JENA needs an ontology
> or other vocabulary file. In the document called "SKOS RDF Schema"[3]
> I have found this Schema : http://www.w3.org/2004/02/skos/core.rdf. Is
> it up to date with the last CR of SKOS Reference ?
>
> I hope I'm clear enough. Feel free to ask me further information.
>
> Regards,
> Thomas Bassetto
>
> [1] This is not the best example :) For specific ID, I have understand
> that <skos:notation/> is better.
> [2]http://jena.sourceforge.net
> [3]http://www.w3.org/TR/2009/CR-skos-reference-20090317/skos.html
>
>
>
>