 |
 |
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 7/13/12 1:52 PM, Corey A Harper wrote:
So, when Karen asked Dan:
Sorry, my question was pretty vague. I mean:On 6/24/12 9:32 AM, Dan Matei wrote:
[URI(Beatles)] [URI(hasAppelation)]
[<name><nosort>The</nosort>Beatles</name>]
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