Re: Re-using and labelling other people's terms

Thanks very much everyone for the replies on this.

Since I wrote my original post, discussion has moved on a little and, 
not surprisingly, has gone further in the direction of greater 
specificity with talk of extra domains and ranges which means that I 
think I'll have rather more sub classes and sub properties than I'd like 
but that's life.

The issue is hurtling towards me one step up the chain actually since, 
with others, I'm about to work on a moving DCAT itself onto the W3C Rec 
Track (through the Gov Linked Data WG) and DCAT includes lots of Dublin 
Core elements so I'm anxious to do this in a way that is semantically 
and socially right. A W3C Rec that in any way implied any change to a 
Dublin Core element would not be good!

Cheers

Phil.

On 30/11/2011 04:00, David Booth wrote:
> And Jeremy's logic also applies to owl:sameAs.  I.e., if people don't
> like it, they don't need to believe you.  So if you have reviewed the
> dangers of using owl:sameAs inappropriately
> http://www.slideshare.net/jpmccusker/owlsameas-considered-harmful-to-provenance
> and you still think it is semantically correct for your purposes, then
> go ahead and use it.
>
> David
>
>
> On Tue, 2011-11-29 at 19:37 -0800, Jeremy Carroll wrote:
>> You could use a subPropertyOf  version of A, B, C ...
>>
>> B is also plausible given your rationale. If people don't like it, they
>> don't need to believe you.
>>
>> foaf:name skos:prefLabel "Please don't use foaf:name, it sucks" .
>>
>> is probably not a consensus reaching triple ....
>> but may be appropriate (or not) in some projects. People who disagree
>> with this triple, might not use your project.
>> What you choose to say about a foreign property, is what you choose to
>> say, nothing more, and nothing less. If someone reads more into your
>> opinion than it merits, that really is their problem not yours.
>>
>> I don't think there is a single truth, and if your truth differs from
>> that of the property authors, well, why is that surprising or difficult.
>>
>> Jeremy
>>
>>
>> On 11/25/2011 7:42 AM, Phil Archer wrote:
>>> Hi,
>>>
>>> A project I'm working on has produced a concept scheme of classes and
>>> properties. I'm now encoding this as an RDF Schema, which is easy for
>>> the terms we're minting, but I'm getting in a twist about terms
>>> defined elsewhere. Rather than use owl:sameAs etc. I want to use the
>>> actual 'foreign' property.
>>>
>>> Context: ADMS is a vocab for describing data catalogues, being
>>> developed under the EU's ISA Programme [1].
>>>
>>> DCAT is the widely used vocab for this sort of thing so we're using a
>>> lot of terms from there as well as from DC and FOAF.
>>>
>>> So here's my question: ADMS has a class 'Asset' that is semantically
>>> identical to DCAT's 'Dataset'. What's the best property to use to add
>>> a lexical label of "ADMS Asset" to the existing term dcat:Dataset ?
>>>
>>> I see several possibilities:
>>>
>>> A) just use rdfs:label. This is potentially bad since a triple store
>>> with both DCAT and ADMS schemata would have multiple rdfs:labels for
>>> the same thing. That's legal, but possibly unhelpful.
>>>
>>> B) use skos:prefLabel. In the context of ADMS, it /is/ the preferred
>>> label but, well, it seems a little rude to use this?
>>>
>>> C) use skos:altLabel. This is probably safest since one can argue that
>>> 'ADMS Asset' is indeed an alternative label for dcat:Dataset, but it
>>> seems odd to use altLabel (only) in a schema of any kind.
>>>
>>> D) define a specific term for "we know it's called foo in the original
>>> but here we call it bar." Who would know to look for it? :-(
>>>
>>> E) get over myself and use owl:sameAs to assert the adms:Asset and
>>> dcat:Dataset are the same.
>>>
>>> I'm tending towards C or possibly A at the moment but it doesn't feel
>>> right.
>>>
>>> Any advice please?
>>>
>>> Thanks
>>>
>>> Phil.
>>>
>>>
>>> [1]
>>> http://www.semic.eu/semic/view/documents/2011-11-15_ADMS_draft_specification.pdf
>>>
>>
>>
>>
>>
>

-- 

Phil Archer
http://philarcher.org/
@philarcher1

Received on Thursday, 1 December 2011 10:09:09 UTC