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/"/>

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

The document excludes certain XML datatypes as well:
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
>>
>> 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 ;-).
>>
>>
>> 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
>> datatypes
>> (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
>>
>> 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