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)]
>>> 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.
My main question is whether the SES is something *different* from
rdfs:datatype, and if so, how is it different? The definition of RDF
"A datatype consists of a lexical space, a value space and a
There is more to this definition at
The document excludes certain XML datatypes as well:
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?
> Sorry for the length of this email. One more coming in reply to the
> Anti-patterns, then will send an agenda for Monday.
> 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:
>> You can see how these appear in the Description Set Profile for ISBD:
>> 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). 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
>> Again, the one RDF datatype that seems similar is the XMLLiteral, which
>> provides these definitions for XML here:
>> 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,
>> 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).
[log in to unmask] http://kcoyle.net