W3C home > Mailing lists > Public > public-esw@w3.org > August 2004

RE: [Proposal][SKOS-Core] Local (non-URI) identifiers for concept s: support for concepts in multiple schemes

From: Miles, AJ (Alistair) <A.J.Miles@rl.ac.uk>
Date: Thu, 19 Aug 2004 15:02:33 +0100
Message-ID: <350DC7048372D31197F200902773DF4C05E50BCA@exchange11.rl.ac.uk>
To: "'public-esw-thes@w3.org'" <public-esw-thes@w3.org>
Cc: "'public-esw@w3.org'" <public-esw@w3.org>

I have a question ...

If a datatype property is declared as an InverseFunctionalProperty, does the
datatype get taken into account when inferring identity of individuals?

I.e. if 'skos:localID' was inverse functional, would the following two
individuals be smushed or not:

ex:individualA  skos:localID  '001'^^<http://example.org/IDtype>

ex:individualB  skos:localID  '001'^^<http://foo.org/IDtype>

??

Al.

---
Alistair Miles
Research Associate
CCLRC - Rutherford Appleton Laboratory
Building R1 Room 1.60
Fermi Avenue
Chilton
Didcot
Oxfordshire OX11 0QX
United Kingdom
Email:        a.j.miles@rl.ac.uk
Tel: +44 (0)1235 445440



> -----Original Message-----
> From: public-esw-thes-request@w3.org
> [mailto:public-esw-thes-request@w3.org]On Behalf Of Dave Beckett
> Sent: 10 August 2004 12:50
> To: Miles, AJ (Alistair) 
> Cc: 'public-esw-thes@w3.org'
> Subject: Re: [Proposal][SKOS-Core] Local (non-URI) identifiers for
> concepts
> 
> 
> 
> On Thu, 5 Aug 2004 12:06:26 +0100 , "Miles, AJ (Alistair) " 
> <A.J.Miles@rl.ac.uk> wrote:
> 
> > 
> > These proposals are in response to the requirements outlined in [1].
> > 
> > (see also the wiki page 
> <http://esw.w3.org/topic/SkosDev/SkosCore/LocalId>)
> > 
> > 2 Proposal A
> > 
> > I suggest to do the following ... 
> > 
> > 1.	Deprecated the skos:externalID property. 
> 
> OK.  The name always confused me.  But I thought it was best practice
> in the community.
> 
> > 2.	Add a new property skos:localId to replace skos:externalID. 
> 
> One problem I have with this as for externalID is a 'l' (ell) and 'I'
> (capital I) together, this is rife for user error. In some fonts they
> can look identical.  
> 
> I'd suggest localID - this is much more consistent with other RDF
> property and syntax naming best practice (rdf:ID, rdf:nodeID,
> rdf:bagID as was).
> 
> Or localName?
> 
> > 
> > 4 Proposal B
> > 
> > I suggest something like the following to cope with 
> requirement B ... 
> > 
> > The skos:localId property be used in conjunction with a 
> blank node and two
> > new properties (e.g. called something like skos:idScope and 
> skos:idValue) as
> > in the following example ... 
> > 
> >    <skos:Concept> 
> >       <skos:prefLabel>Penguins</skos:prefLabel> 
> >       <skos:inScheme 
> rdf:resource="http://www.example.com/thesaurus"/> 
> >       <skos:localId rdf:parseType="Resource"> 
> >          <skos:idValue>A8NH5</skos:idValue> 
> >          <skos:idScope 
> rdf:resource="http://www.example.com/thesaurus"/> 
> >       </skos:localId> 
> >    </skos:Concept> 
> 
> 
> This is trying to invent global identifiers for strings, ie adding
> a URI to qualify them.
> 
> The minmum you need to do this is an RDF datatype to give an RDF
> datatype to the literal.  No need for new nodes, properties 
> or triples:
> 
>   <skos:Concept> 
>      <skos:prefLabel>Penguins</skos:prefLabel> 
>      <skos:inScheme rdf:resource="http://www.example.com/thesaurus"/> 
>      <skos:localID 
> rdf:datatype="http://example.org/id1">A8NH5</skos:localID> 
>      <skos:localID 
> rdf:datatype="http://example.org/id2">ABCD</skos:localID> 
>   </skos:Concept> 
> 
> which gives you two 'local' identifiers that can be distinguished.
> The URIs are given here for examples but could either be tied to
> the multiple thesaurus
>  - maybe a new property from the skos:conceptScheme could list the
>    supported local identifier URI
>  - or just use the skos:conceptScheme URI as the type
> 
> 
> You should also motivate the Proposal B by expanding it to match the
> requirement which wants to
>    "allow concepts to be a member of more than one concept-scheme"
> 
> My example above nearly does that, just add another skos:inScheme.
> 
> 
> > 
> > So proposal B contains the following actions ... 
> > 
> > 1.	Add a new property called something like skos:idValue 
> with domain
> > rdf:Resource and range rdf:Literal. 
> > 2.	Add a new property called something like skos:idScope 
> with domain
> > rdf:Resource and range skos:ConceptScheme. 
> > 
> > 
> > Al.
> > 
> > 
> > [1] 
> http://lists.w3.org/Archives/Public/public-esw-thes/2004Aug/0022.html
> 
> Dave
> 
Received on Thursday, 19 August 2004 14:03:05 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 8 January 2008 14:11:13 GMT