W3C home > Mailing lists > Public > semantic-web@w3.org > March 2011

Properties vs datatypes vs resources

From: Peter Williams <pezra@barelyenough.org>
Date: Sat, 26 Mar 2011 17:21:25 -0600
Message-ID: <AANLkTik3mHN=hzXHVgzXR_B=P0yOj-wnber_TFqgnJ11@mail.gmail.com>
To: semantic-web@w3.org
I have a vocabulary in which am recording information about files
using rdf.  That information is potentially invalidated by any changes
to the files.  Therefore i need a way to authenticate whether the
contents of the file are the same over time.  This will be achieved
using on or more message authentication codes[1] for the files.   For
example, a sha1 and/or sha512 hash of the file.  However, i need this
mechanism to be extensible.

I have considered three different approaches but i am not sure which is best.

 1) have a different property for each type of mac algorithm and have
the codes be literal string values.
 2) define a datatype for each authentication algorithm and have a
single `contentAuthCode` whose domain is typed literals.
 3) have a single `contentAuthCode` property whose domain is an
AuthCode resource.  The algorithm and the code itself would be values
of properties of authentication code resources.

I see option 1 as a little hard to extend because every new mac
algorithm would require a new property.  It is the approach that the
crypto vocabulary[2] in the w3c swap takes.  However, that vocabulary
only supports a couple of algorithms and it does not seem to have been
used very widely, or updated in a long time.

Option 2 seems really elegant but i don't see many vocabularies using
datatypes in this way.  Is that because there are subtle issues with
this approach?

Option 3 is would definitely work but seems a little overly complicated.

I'd love to hear any thoughts you have on these or other approaches to
solving this problem.

[1]: http://en.wikipedia.org/wiki/Message_authentication_code
[2]: http://www.w3.org/2000/10/swap/crypto#

Received on Saturday, 26 March 2011 23:21:58 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:48:24 UTC