Re: Natural Keys and Patterned URIs

On 13 April 2010 22:00, Leigh Dodds <leigh.dodds@talis.com> wrote:
> Hi Patrick,
>
> On 10 April 2010 17:44:06 UTC+1, Patrick Logan <patrickdlogan@gmail.com> wrote:
>> Ah, never mind. I think I found the answer... Literal Key. Perhaps the
>> other patterns should mention this and include Literal Key in the
>> "Related" section?
>
> I'll make sure there are some extra cross-references.
>
> The discovery aspects are interesting here as ideally you want to look
> them up based on a known "identifier property" that stores the Literal
> Key.
>
> OWL 2 has some support for defining keys and I ought to reference this
> from the pattern.
>
> There also needs to be some discussion around using dc:identifier or
> sub-properties. The former can be easier to discover "is there any
> resource with X as an identifier", while the latter can carry more
> semantics. An intermediary position is to use dc:identifier with a
> Custom Datatype. SKOS encourages the latter via skos:notation is
> always has to have a datatype associated with it.

skos:notation with a custom datatype is just as hard to find as
dc:identifier with a custom datatype, or merely a custom predicate
with a simple plain literal string. Either way, you have to know
exactly which URI's people are using for the datatype or predicate, so
the discovery or semantics of each scheme are exactly the same. There
is no discovery advantage in my opinion to using custom datatypes
where predicates are equally suitable, as there is no ability to match
?uri skos:notation "123.23". if the data is actually ?uri
skos:notation "123.23"^^mydatatype . without treating all of the
objects as plain string literals. There doesn't seem to be any
advantage to using the datatype if people have to go through ?uri
skos:notation ?object . filter(str(?object) = "123.23") to get there,
and then they could have overlaps with other schemes anyway.

If you are looking for a predicate that is defined as a key, then you
could still have overlaps between schemes, as you are not recognising
the predicate explicitly. In all of the methods, one needs to know
they are looking for an identifier, and know what scheme the
identifier is defined in to get exact access, and in all of the cases
one may have overlaps if they only know they are looking for an
identifier without knowing which scheme it is defined in, so there is
no semantic difference.

All comes down to accessibility I think. If you want the scheme to be
more accessible to people who know the identifier but not the scheme
than string plain literals with a custom predicate is more useful. If
you want the scheme to be more accessible to people who know the
scheme, but want to know the identifier, than the standard predicates
, is, dc:identifier or skos:notation (w/ custom datatype) are more
useful. If the patterns document wants to portray the advantages of
different methods, rather than just giving best practices, then the
advantages of both methods could be explained.

Cheers,

Peter

Received on Tuesday, 13 April 2010 21:57:33 UTC