[tei-council] <notatedMusic> changes required

Thu Jul 7 16:23:15 EDT 2011

On 11-07-07 11:02 AM, Gabriel Bodard wrote:
> (I'm not sure how this matters, but some ptrs presumably point to
> internal elements or anchors in the same file?)

Of course you're right; I was thinking about pointers pointing outside 
the document. But the syntax of data.pointer surely makes it explicit 
whether @target is pointing outside the document or not.

On 11-07-07 11:05 AM, Martin Mueller wrote:
 > 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.

Nothing at all is wrong with it; my question is why this is suddenly an 
issue with <notatedMusic> when it's not an issue anywhere else in the 
guidelines. I'm just working from Raffaele's original text, which I 
amended as little as possible when including it. He says, in his 
explanation of <notatedMusic>:

<q>
     ptr can be used to indicate the location of a representation of the 
music notation.

     @mimeType supplies the MIME type of the data format, when available.

     [...] An external representation of the notated music is specified 
using the ptr element, whose target attribute provides its 
electronically-accessible location.
</q>

He doesn't make any claims about what could or should be done with the 
content, whatever it is.

But if the consensus is that any <ptr> element in a guidelines example 
pointing at an XML file should have @type="transclude", then I'll 
certainly add it. You haven't convinced me, but I do seem to be outnumbered.

Cheers,
Martin

On 11-07-07 11:05 AM, Martin Mueller wrote:
> 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
>
>
> .
>

-- 
Martin Holmes
University of Victoria Humanities Computing and Media Centre
(mholmes at uvic.ca)