RE: ADMS RDF

Phil,

I agree with Dave's suggestion about simply using skos:Concept as the range of properties like interoperabilityLevel, etc.

This should be sufficient as long as there isn't anything special about the concepts that can be used as the range of values. That is, any SKOS Concept is OK. 

I am not sure if this is the case. Based on the comment being attached to skos:Concept and some other documentation, it seems that something must (?) be put in the skos:notation field in order to comply with the vocabulary. If this is true, then I would create a subclass of skos:Concept, define it appropriately and use it as the range of the properties.

I would also recommend that http://www.w3.org/ns/adms distinguished properties that are links between resources not only by saying it in the description, but by also specifying their type as ObjectProperty.

Regards,

Irene Polikoff 
Mobile Phone: +1 914-329-8576
CEO, www.topquadrant.com, @TopQuadrant
Voyages of the Semantic Enterprise
Trainings: Introduction to Semantic Web Technologies: What They are and How to Use Them - Next Class, Sept 10-13, 2012 ;
TopBraid Suite Advanced Product Training - Next Class, Sept 24-27 , 2012



-----Original Message-----
From: Phil Archer [mailto:phila@w3.org] 
Sent: Friday, August 03, 2012 12:34 PM
To: Dave Reynolds
Cc: W3C public GLD WG WG
Subject: Re: ADMS RDF

That makes sense, yes (defining a range). OK, I'll work on that. It 
feels like a good use of Occam's Razor, always the best tool in the box.

Thanks

Phil.

On 03/08/2012 17:07, Dave Reynolds wrote:
> Hi Phil,
>
> On 03/08/12 16:10, Phil Archer wrote:
>> Pls see below
>>
>> On 28/06/2012 16:10, Dave Reynolds wrote:
>>> Hi Phil,
>>>
>>> Follow up from GLD call ... glancing at the ADMS document I noticed some
>>> oddities that are reflected in the RDF [1].
>>>
>>> Specifically, there are a number entities that look like aliases for
>>> skos:Concept. For example:
>>>
>>> <rdf:Description rdf:about="&skos;Concept">
>>>      <rdfs:label xml:lang="en">Asset Type</rdfs:label>
>>>      <rdfs:comment xml:lang="en" rdf:parseType="Literal">The
>>> skos:Concept class fully represents the ADMS class of Asset Type (see
>>> section on the <xh:a xh:href="#Code">Code</xh:a> datatype for
>>> details).</rdfs:comment>
>>>      <vann:usageNote xml:lang="en">Used in ADMS to provide a
>>> classification of a Semantic Asset according to a controlled vocabulary,
>>> e.g. code list, metadata schema.</vann:usageNote>
>>>      <rdfs:isDefinedBy rdf:resource="&skosDoc;" />
>>>      <dcterms:identifier>skos:Concept</dcterms:identifier>
>>>    </rdf:Description>
>>>
>>> With similar declarations for: "Code", "Interoperability Level",
>>> "Representation Technique" and "Status".
>>>
>>> I suspect this is a slip and that the intention was to introduce actual
>>> classes which would be sub-class (or equivalent-class) to skos:Concept.
>>>
>>> [If it's not a slip then this is a modelling style which I would prefer
>>> us to avoid. It means that we are assigning alternative labels to
>>> skos:Concept itself - which is problematic both technically and
>>> socially.]
>>
>> Thanks Dave,
>>
>> It's taken me too long to get to this but, well, I have now.
>>
>> It's a slip and it's not a slip - more of a compromise I'm very happy to
>> change because I don't like it for all the reasons you give.
>>
>> I raised the issue back in November [1] (actually, I swear I've raised
>> it more than once. I remember getting a reply from someone at Top
>> Quadrant I hadn't heard of but I can't find it). The basic problem is
>> that we're defining a vocabulary that uses other people's terms but that
>> doesn't mean we don't have something to say about them.
>>
>> What I want to say here is: the way to encode the ADMS Asset Type is to
>> use a skos:Concept. In his reply to my question, Jeremy said I could use
>> sub properties/classes. Well, yes, I know that, but I really don't want
>> to - I want to say *use skos:Concept*. JJC then said that if people
>> didn't like whatever new labels were added, they didn't have to use
>> them, which is true of course. The e-mail I can't find from another TQ
>> person made the same point, i.e. you can say what you like and other
>> people decide whether to take any notice. With this in mind I was
>> slightly more ready to add new labels to existing classes although in my
>> sign off from that thread [2] I expressed exactly the worry as you end
>> with in almost the same terms ("...DCAT includes lots of Dublin Core
>> elements so I'm anxious to do this in a way that is semantically and
>> socially right.")
>
> So I agree with JJC that it is legal to add your own labels to other
> people's terms. However, it is a potential mild barrier to uptake that
> might be better avoided if it can.
>
> In particular, in this case your aliases are rather narrow. So anyone
> using skos:Concept seeing a label for it such as "Interoperability
> Level" is likely to be confused. It only makes sense in the context of
> ADMS and so is really a property of ADMS not of skos.
>
> To say "use skos:Concept" here then you do that through rdfs:range
> statements as you have done (or owl:Restrictions). I don't see you need
> anything else.
>
>> But, if it is not right to add new labels to existing terms - and I
>> agree entirely, I don't think it is - how can we proceed?
>
> Just use the range declarations and stop there. You already have things
> like:
>
> adms:interoperabilityLevel
>     rdfs:label "interoperability level"@en;
>     rdfs:comment "Links a resource to its adms:InteroperabilityLevel.
>                  Since this is encoded using skos:Concept, that is the
>                  defined range for this property."@en;
>     rdfs:range skos:Concept .
>
> That seems sufficient to me. Though I would rephrase it without the
> mention of the non-existent curie
>
>
> adms:interoperabilityLevel
>     rdfs:label "interoperability level"@en;
>     rdfs:comment "Links a resource to its Interoperability Level, which
>                   should be encoded using skos:Concept."@en;
>     rdfs:range skos:Concept .
>
>> I haven't
>> updated the schema in w3.org space yet but I have prepared a version
>> that I hope is better in this regard - although it still doesn't feel
>> right [3]. The key bit is:
>>
>> <http://www.w3.org/2004/02/skos/core#Concept>
>>    rdfs:label "Concept"@en ;
>>    rdfs:comment """The skos:Concept class fully represents the following
>> ADMS classes:
>>     - Asset Type
>>     - Code
>>     - Interoperability Level
>>     - Representation Technique
>>     - Status
>> In each case, the use of a Concept from a suitable Concept Scheme will
>> provide a suitable value from a controlled vocabulary. In the particular
>> case of the ADMS data type of Code, the intention is that the
>> skos:Concept class be used as follows:
>>   - for the content property, use skos:notation
>>   - the ADMS list property will be taken care of by means of the
>> skos:inScheme property;
>>   - the list agency property is likely to be applied to the scheme as a
>> whole for which dcterms:creator is appropriate;
>>   - the list version property can be fulfilled using schema:version.""" ;
>>    rdfs:isDefinedBy <http://www.w3.org/TR/skos-reference/> ;
>>    dcterms:identifier skos:Concept .
>
> So I won't formally object to that but it seems unnecessary and slightly
> confusing.
>
> That makes more sense to me as part of the documentation of ADMS. For
> example it could be a comment on the Ontology resource to explain how
> the mapping from the ADMS abstract model has been done in the RDF. Or it
> could be in some separate documentation which is linked to the ADMS
> Ontology resource via rdfs:seeAlso or similar.
>
> It's not really a comment on skos:Concept.
>
> Dave
>
>
>

-- 


Phil Archer
W3C eGovernment
http://www.w3.org/egov/

http://philarcher.org
+44 (0)7887 767755
@philarcher1

Received on Friday, 3 August 2012 17:15:39 UTC