 |
 |
Thanks, Richard, for putting this into perspective. On 6/25/12 9:01 AM, Richard Urban wrote: > > I don't see how something like ISBD fits this definition of a datatype. > Is there a concept that better fits how we use ISBD? In the RDF datatype > documentation, "RDF provides for XML content as a literal value" (i.e. a > string which contains XML markup is it's own datatype defined as the > class "XMLLiteral"). (see > http://www.w3.org/TR/rdf-concepts/#section-XMLLiteral) Importantly, this > datatype is disjoint from the value space of other XML datatypes (i.e. > dates, integers, etc.). It seems more appropriate to me that ISBD, like > XML, should be considered a markup language rather than a datatype. We'll need to wait for Jon and Gordon to weigh in, but I know that Jon has been at a conference and may be in the midst of lengthy travels. However, they have indeed created a number of SES's that are not "formal" datatypes in the sense you mean, both in RDA in RDF and ISBD in RDF. It's easier to see in the latter because each ISBD area is treated as an SES: http://metadataregistry.org/schemaprop/show/id/2135.html You can see how these appear in the Description Set Profile for ISBD: http://wiki.dublincore.org/index.php/DCAM_Revision_ISBD_DSP While these have been declared as SES's, I don't believe that they are actionable at the moment, in the sense that I don't know of a "mapping rule" for the declared SES's. Nor is it clear to me the relationship of the declared SES and the ISBD RDF properties for that area. So let's hope Jon's travels go well and he arrives refreshed ;-). kc > > I don't think DCAM would want to add a similar class of "ISBDLiteral" > (I'd prefer to leave that to someone developing an Application Profile > that needs to use ISBDLiterals), however we would need a new class in > addition to plain/typed that we currently have. Given the extent to > which "syntax encoding scheme" is already used within DC documentation > to refer to formal datatypes, it may be necessary to coin a new term > that denotes this class of more complex representation types. (it's a > bit of a minefield, so I'd like to think more on it before offering > suggestions). > > Richard J. Urban, Assistant Professor > School of Library and Information Studies > College of Communication and Information > Florida State University > [log in to unmask] <mailto:[log in to unmask]> > @musebrarian > > On Jun 24, 2012, at 4:22 PM, Karen Coyle wrote: > >> On 6/24/12 9:32 AM, Dan Matei wrote: >> >>>>> [URI(Beatles)] [URI(hasAppelation)] >>>>> [<name><nosort>The</nosort>Beatles</name>] >>>> >>>> What makes the value here an SES rather than a literal? In the case of >>> >>> Maybe a consuming application produces both a display form and a sort >>> key. >> >> Sorry, my question was pretty vague. I mean: how is a consuming >> program to know if this is a literal or an SES? In RDF there is a >> datatype, which appears to be quite liberal in application: >> >> "with an additional rdf:datatype="datatypeURI" attribute on the >> property element. Any RDF URI reference can be used in the attribute." [1] >> >> The DCAM SES is defined as: >> >> "syntax encoding scheme (http://www.w3.org/2000/01/rdf-schema#Datatype) >> A set of strings and an associated set of rules that describe a >> mapping between that set of strings and a set of resources. The >> mapping rules may define how the string is structured (for example >> DCMI Box) or they may simply enumerate all the strings and the >> corresponding resources (for example ISO 3166)." [2] >> >> So I'm wondering what constitutes a "mapping rule"? RDF does not >> appear to require a mapping rule, only a URI that defines (in some >> way) a datatype. Is the DCAM SES intended to be more strictly defined >> than the RDF:datatype? If not, is there a reason to define the SES if >> it is the same as the RDF:datatype? >> >> Shouldn't the examples here include the URI for the datatype/SES? Is >> that all that is required to make these valid DCAM? >> >> >> kc >> [1] http://www.w3.org/TR/REC-rdf-syntax/#section-Syntax-datatyped-literals >> [2] http://dublincore.org/documents/abstract-model/#sect-7 >>> >>>> documentation in PDF enough to qualify as a "mapping rule"? Does a >>>> mapping rule have to be machine-actionable, e.g. in the case above would >>>> an XML schema be a mapping rule? And how will mapping rules for >>>> RDF-defined properties be expressed (since RDF, as I understand it, does >>>> not actually constrain in the sense that XML schema does). >>> >>> I don't know the canonical way of associating a SES with an RDF >>> statement. I would use (shamelessly) reification :-) >>> >>>>> >>>>> [URI(Dostoyevsky)] [URI(hasAppelation)] >>>> [<firstName>Fyodor</firstName><patronimic>Mikhaylovich</patronimic><surname>Dostoyevsky</surname>] >>> >>> Or, in this case, a useful form would also be: >>> >>> [URI(Dostoyevsky)] [URI(hasAppelation)] [Fyodor >>> Mikhaylovich<b>Dostoyevsky</b>] >>> >>> using HTML as SES. >>> >>> Dan >>> >> >> -- >> Karen Coyle >> [log in to unmask] <mailto:[log in to unmask]> http://kcoyle.net >> ph: 1-510-540-7596 >> m: 1-510-435-8234 >> skype: kcoylenet >> > > > > > > > > > -- Karen Coyle [log in to unmask] http://kcoyle.net ph: 1-510-540-7596 m: 1-510-435-8234 skype: kcoylenet