 |
 |
Hi Karen, Yes, I think that is the main question in front of us, and I think it's an important topic for Monday's call. My instincts tell me that it *is* different. Jon & Tom have said it's a subclass of rdfs:Datatype, but I'm starting to wonder if it's not the other way around. In either case, though, I think the important thing is to define some properties, perhaps aligned with VOID properties, that allow us to enrich the definition of an SES with additional metadata, including links to parsers, reference code, or XSLTs; descriptions of the syntax used; and other information about tools, context, and producing / consuming applications that might be of value. I may be wrong here, but this is how I see DCAM & DCAP playing off each other: DCAM defines the properties and model for this kind of data so that an individual DCAP can then represent as much info about vocab as a whole as well as the individual properties used. Hopefully that makes some sense. Thanks, -Corey Metadata Services Librarian 212.998.2479 On Jul 14, 2012 10:18 AM, "Karen Coyle" <[log in to unmask]> wrote: > On 7/13/12 1:52 PM, Corey A Harper wrote: > > So, when Karen asked Dan: >> >>> On 6/24/12 9:32 AM, Dan Matei wrote: >>>>>> [URI(Beatles)] [URI(hasAppelation)] >>>>>> [<name><nosort>The</nosort>**Beatles</name>] >>>>>> >>>>> Sorry, my question was pretty vague. I mean: >>>> how is a consuming program to know if this is a literal or an SES? >>>> >>> >> The answer is, because the AP makes that explicit, and that AP's URI >> comes with explicit, machine readable instructions & reference code >> for decoding and mapping that SES to *something*. That something could >> be specific to an implementation. It could be idiomatic JSON (with or >> without a corresponding class of object in some programming language, >> or RDF-XML, or a SOLR schema, or... >> > > Corey, yes, fine, but HOW? That's the question, in my mind. How does the > AP make that explicit? It could be by defining an rdfs:datatype for the > SES. That would formally declare it, and presumably the URI of the datatype > would (best practice) lead to a definition (human readable and/or > machine-actionable) of the datatype and to the mapping, e.g. > > <rdfs:Datatype rdf:about="http://myexample.**com/karensSES/<http://myexample.com/karensSES/> > "/> > > My main question is whether the SES is something *different* from > rdfs:datatype, and if so, how is it different? The definition of RDF > datatype is: > > "A datatype consists of a lexical space, a value space and a > lexical-to-value mapping." > > There is more to this definition at > http://www.w3.org/TR/2004/REC-**rdf-concepts-20040210/#** > section-Datatypes<http://www.w3.org/TR/2004/REC-rdf-concepts-20040210/#section-Datatypes> > > The document excludes certain XML datatypes as well: > http://www.w3.org/TR/2004/REC-**rdf-mt-20040210/#dtype_interp<http://www.w3.org/TR/2004/REC-rdf-mt-20040210/#dtype_interp> > > That's a discussion that I'm not sure I am going to be able to understand. > But it all brings me back to: > > Is the DCAM SES different from the rdfs:datatype? If so, how? And if so, > how do we express this formally? > > kc > > > > > >> Sorry for the length of this email. One more coming in reply to the >> Anti-patterns, then will send an agenda for Monday. >> >> -Corey >> >> On Thu, Jul 12, 2012 at 11:21 AM, Richard Urban >> <[log in to unmask]> wrote: >> >>> Hi all, >>> >>> Looping back around to this… >>> >>> >>> On Jun 26, 2012, at 9:04 AM, Karen Coyle wrote: >>> >>> >>> 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<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<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 ;-). >>> >>> >>> Here may be where I am confused. According to the current DCAM >>> documentation, a "syntax encoding scheme" **IS** an RDF Datatype >>> (http://www.w3.org/2000/01/**rdf-schema#Datatype<http://www.w3.org/2000/01/rdf-schema#Datatype>). >>> And simply declaring that >>> ISBD *IS* an SES (or particular ares are), doesn't necessarily make it >>> so. >>> RDF defers to the XML Schema specifications for defining a preset list of >>> datatypes, but also provides the criteria for extending it to include new >>> datatypes >>> (http://www.w3.org/TR/2001/**REC-xmlschema-2-20010502/#** >>> datatype-components<http://www.w3.org/TR/2001/REC-xmlschema-2-20010502/#datatype-components> >>> ). >>> >>> Again, the one RDF datatype that seems similar is the XMLLiteral, which >>> provides these definitions for XML here: >>> http://www.w3.org/TR/rdf-**concepts/#section-XMLLiteral<http://www.w3.org/TR/rdf-concepts/#section-XMLLiteral> >>> >>> Can we provide a similar definition for ISBD, assuming the work that >>> ISBD >>> AP group does produce a model of IBSD that would be equivalent to the XML >>> model. (this needs some more investigation, IMHO). >>> >>> Lexical Space >>> is the set of all strings >>> >>> which are self-contained ISBD content (??) >>> (ISBD does not indicate a character encoding space, I presume this is >>> deferred to the MARC format for electronic records) >>> for which the embedding between an arbitrary ISBD tag (??) yields a >>> document >>> conforming to the ISBD namespace (???) >>> >>> The value space >>> is a set of entities, called ISBD values, which is: >>> disjoint from the lexical space; >>> disjoint from the value space of any XML schema datatype (Does ISBD have >>> it's own sub-data types, i.e. dates. enumerated list of abbreviations, >>> etc.??) >>> and in 1:1 correspondence with the lexical space >>> >>> The lexical-to-value mapping >>> is a one-to-one mapping from the lexical space onto the value space… >>> >>> This is just a quick paraphrasing of the XML Literal documentation, I >>> have >>> not thoroughly tested whether this is actually a valid definition of an >>> ISBD >>> Literal datatype. >>> >>> If this is *not* what we want to do to accommodate ISBD here, it may be >>> necessary to relax the DCAM's specification of what an SES is (i.e. >>> remove >>> the requirement that an SES isA RDF Datatype). >>> >>> Richard >>> >>> >>> >>> >>> >>> >>> >> >> >> > -- > Karen Coyle > [log in to unmask] http://kcoyle.net > ph: 1-510-540-7596 > m: 1-510-435-8234 > skype: kcoylenet >