Re: Properties vs datatypes vs resources

>>>>> Peter Williams <pezra@barelyenough.org> writes:

[…]

 > 1) have a different property for each type of mac algorithm and have
 > the codes be literal string values.

 Personally, I'm somewhat inclined towards this approach.
 However, I'd rather use typed literals, and allow both
 “xmls:hexBinary” (used traditionally) and “xmls:base64Binary”
 (lower space and bandwidth costs) types for the value.

 > 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.

 The algorithm could be a class of the node, and the code itself
 as its rdf:value.  E. g.:

:file my:contentAuthCode [
    a         mac:SHA-1
    rdf:value "SGVsbG8hIChOQiAxNjAgYml0cyk="@xmls:base64Binary
]

 > I see option 1 as a little hard to extend because every new mac
 > algorithm would require a new property.

 I see this as no different to 2 requiring a new datatype, or 3
 requiring a new “owl:Thing”.

 Moreover, with OWL, relationships between classes (or things)
 could be specified, so that the application could find out even
 the MAC's codes it doesn't support (e. g., for the user to
 verify using other tools.)

 Either way, I'd rather have the MAC's defined by a distinct
 vocabulary, with an update policy allowing for faster updates
 (i. e., shorter expert and editor review periods, etc.)

[…]

 > 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?

 Somehow, I thought that there aren't a vocabulary to define
 relationships between datatypes in RDF.  On the contrary, for
 classes and things, there's OWL.

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

 I see little reason to prefer 3 over 1 as long as all the MAC's
 are a single bit string.  If, however, there's a MAC that's a
 structured value instead (though I've never heard of one; but
 one may wish to consider HMAC's), 3 could be more appropriate.

 > 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#

-- 
FSF associate member #7257