Re: SVG document types

Hello James,

this is the same and all these approaches are related.
Unsing RDFa means to put elements from other (own) namespaces into the 
document, only referring to an own specification to declare the meaning of the 
element or its content. For this the role attribute is the simplest approach,
RDFa has some more advanced options.

SVG in general allows elements from other namespaces, but only in specific
areas as metadata or foreignObject.
Attributes from other namespaces are no problem, normal viewers simply ignore 
them, in case of RDFa and the role attribute those contain only metadata about 
the meaning, not the presentation.
Of course, specific parsers can be used to extract metadata information and 
expose it somehow to the interested audience.

Therefore foreign elements in metadata or foreignObject do not cause conflicts,
attributes with another namespace indication do not either.
For example programs like Inkscape use them for their own purposes,
they use RDF in metadata as well - this is often used to provide machine 
readable text information about the work, the author, licenses etc.
 
Concering your namespace xmlns:musicSVG1="http://www....":
Of course then your elements within metadata or foreignObject or your
own attributes have to be indicated to belong to this namespace.
RDFa 1.0 uses a (pseudo)-namespace approach as well to indicate
to which namespace the content of the RDFa attributes belongs, to ensure, that 
these indication have a defined meaning.
If a parser knows the used namespaces, it can expose the meaning and structure
to the audience.

If your specification for musicSVG1 precisely defines structure and meaning of 
some music issue, a parser has to know this specification to connect the
values of a role-attribute or RDFa attributes to the entries in your 
specification, indicated by the namespace information.

For example some years ago I specified LML, a markup language for literature, 
because neither SVG text elements nor XHTML indicate much of the semantic 
meaning of structures in XHTML or SVG documents, for example one cannot 
identify strophes, stanzas, strophe lines from poetry in such formats, but 
with the role attribute or with RDFa now one can point to LML elements to 
indicate such meaning for text content in XHTML or SVG documents.

There are other languages for other purposes, so why not for music?
If some graphical structures in an SVG file represent notes, frequencies, 
rhythm, times, sound volume etc, it sounds reasonably for me to provide 
information about this within the SVG with one of the approaches.

Maybe at some point of complexity one has to use a format like SMIL to compose 
something with more complexity, joining together documents from different  
formats instead of trying to extent one format for everything.

Another option is of course, if finally the idea is to present the music 
information audible to the audience and adding only additionally graphical 
information as notes, it is an option too to embed SVG fragments into some 
Music Markup Language and not to extent SVG to present music somehow in an 
audible way.
The element audio in SVG tiny 1.2 or in HTML5 seem to be only intended for
'noise'-files, not for some markup to represent the 'noise' itself in such a 
way, that the parser interprets it from notes and related markup.
If one only needs to combine such 'noise'-files with for example animated
SVG, of course this is possible with such an audio element in SVG tiny 1.2,
but unfortunately the usual current browsers ignore this audio element.

Olaf
 


Dienstag 22 November 2016, 14:59:22:
> Hi Olaf, all,
> 
> Thanks, Olaf, for your thoughts. I've taken a look at RDFa, but can't
> see how to use it to define a simple container structure in SVG. Maybe I
> should look a bit harder, but RDFa seems to be just about adding more
> powerful attributes. Possibly the attributes could then say that a
> particular element belongs to a particular container, but I think it
> would be easier to parse the file (and it could be kept smaller and
> simpler) if it really had a known structure.
> One of the main use-cases for such files is the extraction of music
> examples. These are much easier to locate, both for software and for
> humans, if the file has a known container structure.
> I'm also a bit wary of depending on standards that are not guaranteed to
> work in all versions of SVG...
> 
> Here's another strategy, that occurred to me just before getting your
> reply. Maybe its related to your alternative c). Comments welcome of course!
> 
> The SVG score file should declare a pseudo-namespace in its header. This
> would look exactly like an ordinary namespace declaration, but the
> declared namespace would not actually be used in the file.
> For example:
>      xmlns:musicSVG1="http://www...."
> 
> Browsers would simply treat this declaration as being superfluous (since
> the namespace is never mentioned again in the file), and display the
> file as usual.
> Applications designed for working with music notation can, however, read
> the declaration to mean that the file conforms to a particular, standard
> container and element class structure called musicSVG1. Those
> applications can then accept or reject the file, depending on whether
> they are expecting to parse files having that type.
> There could also be a standard *verifier* application (like the W3C HTML
> verifier) that would read the file and report any inconsistencies. This
> would be used by the *writers* of musicSVG1 files to check that the file
> is being written correctly. Writing a verifier application for musicSVG1
> (and other possible music formats) would be quite straightforward. (I
> could do it myself.)
> 
> Namespaces and file types are closely related concepts, but I'd prefer
> not to have to override the namespace declaration. Is there a better
> alternative?
> 
> All the best,
> James
> 
> Am 22.11.2016 um 12:15 schrieb Dr. Olaf Hoffmann:
> > Hello,
> > 
> > this sounds like metainformation.
> > My idea would be to use something like RDF(a) to provide a defined
> > semantic
> > meaning.
> > In SVG tiny 1.2 you can use both the attribute role and RDFa attributes
> > within the SVG namespace for this.
> > In SVG 1.1 there is no RDFa - this seems to apply unfortunately for the
> > SVG 2 working draft as well. In the SVG 2 working draft the role
> > attribute seems to be restricted to another purpose, therefore not
> > applicable to provide defined semantic information from an own namespace
> > unfortunately, this feature is borked by the draft.
> > 
> > Therefore here you have other options to consider for SVG 1.1 (maybe in
> > the
> > future for SVG 2 as well, if this is not improved at least to the level of
> > SVG tiny 1.2 anymore):
> > a) Use RDFa attributes from the XHTML namespace
> > b) Use RDF within an element metadata for each element you want to provide
> > semantic metainformation. Obviously it is slightly more complex to extract
> > such information and the file size gets bigger.
> > c) Of course, if you provide a role attribute from you own namespace, it
> > can contain defined information as well. For example this approach is
> > used in the standard for digital books EPUB 3 (only for the XHTML part of
> > the content, no idea why not for the SVG part as well).
> > 
> > Olaf

Received on Tuesday, 22 November 2016 15:27:48 UTC