First, I put a copy of ISBD in English at:

http://kcoyle.net/temp/isbd2007.pdf

since none is available on the ISBD site. This may be slightly out of 
date, but I assume it is sufficient for our purposes. At the time I 
pointed folks to pages 21-22 which give a concise map of ISBD areas and 
properties.

On 7/11/12 6:35 AM, [log in to unmask] wrote:

>
> E. The date is preceded by a comma, space (, ).
> G. The place of printing or manufacture, name of the printer or manufacturer and
> date of printing or manufacture (for older monographic resources, when recorded
> as a statement distinct from the publishing statement) are enclosed in one pair
> of parentheses ( ( ) ). Within the parentheses the same punctuation is used as
> in B, C and E.
>

Gordon, if this is the SES mapping for the ISBD string, then this does 
make sense to me. This fits in with the 8 (9?) Area properties, and the 
decoding algorithms exist because this is exactly what ISBD was designed 
for: decoding of the strings using punctuation.

However, the definition of ISBD in RDF creates properties for the 
individual elements within those area strings:

http://metadataregistry.org/schemaprop/show/id/1957.html
   -- for "hasPlaceOfPublicationProductionDistribution"

and the AP places these within an SES:

<StatementTemplate ID="hasPublicationProductionDistributionEtcArea" 
minOccurs="1" maxOccurs="1" type="nonliteral">
       <Property>http://iflastandards.info/ns/isbd/elements/P1162</Property>
       <!-- Area 4 is an aggregated statement with SES -->
       <NonLiteralConstraint 
descriptionTemplateRef="DThasPublicationProductionDistributionEtcArea"> 

         <ValueStringConstraint>
 
<SyntaxEncodingScheme>http://iflastandards.info/ns/isbd/elements/C2007</SyntaxEncodingScheme>
         </ValueStringConstraint>
       </NonLiteralConstraint>
     </StatementTemplate>

It's the use of individual properties within an SES, not the use of the 
ISBD punctuation within a string, that I find problematic. This would be 
analogous to DC BOX. However, I am questioning that one can use ISBD 
properties in this way due to the dependence on the order of elements in 
the original string.

What would make sense to me would be to create the areas as SES's, and 
then have a separate set of areas that are classes with properties for 
the individual elements of ISBD as members of those classes.

kc


> There is also a set of punctuation patterns intended to cover the most
> commonly-encountered situations. Examples from area 3:
>
>   . — Place of publication or production : name of publisher or producer, date
>   . — Place of publication or production ; place of publication or production :
> name of publisher or producer, date (place of printing or manufacture ; place of
> printing or manufacture : name of printer or manufacturer, date)
>
> Algorithms and code for encoding ISBD aggregated statements/area strings exist.
> It may be possible to develop decoding algorithms, which would be very useful
> for parsing ISBD aggregated statements into strings which could be referenced as
> things. This is the use case I mentioned in the last telecon [3].
>
> ISBD punctuation is relevant to aggregated statements and SESs for MARC21, as
> shown in the DCAM design pattern for Publication statement [4]. The ISBD
> punctuation is embedded in the content (strings) of MARC21 records. This is no
> longer (and in some quarters, never has been) considered good practice, but it
> does lead to a simple SES encoding algorithm: concatenate the element strings
> with a space ( ) delimiter in the order in which they appear. This is discussed
> in [5].
>
> I hope this helps. Some of the discussion has, for me, become quite tantalizing
> [6]
>
> btw, if anyone thinks it would be helpful to have access to the text of ISBD
> (for research purposes such as this discussion), let me know. I may be able to
> put a PDF copy on the wiki ...
>
> Cheers
>
> Gordon
>
> [1]
> http://leo.cilea.it/index.php/jlis/article/download/urn%3Anbn%3Ait%3Aunifi-3793/4408
> [2] http://www.w3.org/2001/sw/wiki/JointMeeting2010
> [3] http://wiki.dublincore.org/index.php/DCAM_Revision/TeleconReport-201206xx
> [4]
> http://wiki.dublincore.org/index.php/DCAM_Revision_Design_Patterns#Publication_statement
> [5] http://managemetadata.com/blog/2012/05/20/taggregations/
> [6] http://en.wikipedia.org/wiki/Tantalus
>
>
>
> On 26 June 2012 at 14:04 Karen Coyle <[log in to unmask]> wrote:
>
>> 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
>

-- 
Karen Coyle
[log in to unmask] http://kcoyle.net
ph: 1-510-540-7596
m: 1-510-435-8234
skype: kcoylenet