[tei-council] <notatedMusic> changes required

Martin Mueller martinmueller at northwestern.edu
Thu Jul 7 14:05:11 EDT 2011


This discussion reminds me of something non-musical that I did some years
ago. I wrote notes on the Iliad and was too lazy to copy bits of text in
Greek and in translation. So I did things like

    <p>The first reference to Achilles in the <title>Iliad</title> is an
event of particular gravity:
    <cit><ptr target="Il.1.1" n="1" type="transclude"/></cit>

The point of ptr type="transclude" was to say that this was not a link but
that it directly embeds some representation of a canonical object into the
text. In some ways it works like a character entity.  It replaces
something (a pointer or entity) with what that something stands for.

If this is a legitimate use of type="transclude", why is there a problem
with alternatives? The default meaning of ptr is that it acts as a link.
One could "explicitate" this, but it doesn't seem necessary.

If I followed the music debate correctly (and I'm not sure whether I did),
a transcluding pointer reference might produce the first few bars of a
Chopin ballade in musical notation as part of the text, and processing
instructions could add a link to a performance. But how does this differ
in principle from my text-centric use, where the transclusion fetches a
line of the Iliad, either in the original, or in translation, or both,
depending on the processing engine.

And if it doesn't, what is wrong with <ptr type="transclude"/> as a
well-understood and reasonably unambiguous instruction to go go some
canonical object or part of it, fetch it, and embed it, as opposed to
linking to it. 

MM



On 7/7/11 12:43 PM, "Martin Holmes" <mholmes at uvic.ca> wrote:

>HI Gaby,
>
>On 11-07-07 09:48 AM, Gabriel Bodard wrote:
>> Then we're getting back to the argument that a different element than
>> <ptr/>  is needed here. Are we just using ptr now because we haven't
>> invented that element yet? If so, why are we so exercised about whether
>> or not it has an attribute value.
>>
>> Perhaps, rather than @type='transclude', which as Martin points out is a
>> bit odd with no @type='non-transclude' to contrast it to, we should just
>> call it @type='externalObject' in honour of the soon-to-be-invented
>>element?
>
>Isn't every <ptr> a pointer to an external object?
>
>Cheers,
>Martin
>
>>
>> G
>>
>> On 2011-07-07 17:31, Sebastian Rahtz wrote:
>>>
>>> On 7 Jul 2011, at 16:15, Martin Holmes wrote:
>>>>
>>>> So why is a<ptr>   inside<notatedMusic>   different from a pointer
>>>> anywhere else?
>>>
>>> because the processing expectation by the man in the street is
>>>different.
>>> the<ptr>s in
>>>
>>> <notatedMusic>
>>>      <ptr target="foo.xml">
>>> </notatedMusic>
>>>
>>> and
>>>
>>> 	<p>See the BBC news (<ptr target="http://www.bbc.co.uk/'/>)</p>
>>>
>>> are just entirely different beasts.
>>>
>>> _Theoretically_ you are correct that the processing agent can
>>> decide what to do, but surely all common sense says that
>>> a processing agent should not have to keep special rules for
>>> <ptr>   to behave differently inside music? Raffaele definitely
>>> expects us to render the two<ptr>   above differently.
>>>
>>> --
>>> Sebastian Rahtz
>>> Head of Information and Support Group
>>> Oxford University Computing Services
>>> 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431
>>>
>>> Sólo le pido a Dios
>>> que el futuro no me sea indiferente
>>>
>>> _______________________________________________
>>> tei-council mailing list
>>> tei-council at lists.village.Virginia.EDU
>>> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
>>>
>>> PLEASE NOTE: postings to this list are publicly archived
>>
>
>-- 
>Martin Holmes
>University of Victoria Humanities Computing and Media Centre
>(mholmes at uvic.ca)
>_______________________________________________
>tei-council mailing list
>tei-council at lists.village.Virginia.EDU
>http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
>
>PLEASE NOTE: postings to this list are publicly archived




More information about the tei-council mailing list