Loading ...
Sorry, an error occurred while loading the content.

SVG?

Expand Messages
  • Ron
    I work for the County Engineer, who maintains the roads in the smaller towns and out in the country. I am working on an app for the Sign Crew. About 10% of our
    Message 1 of 7 , May 4, 2004
    • 0 Attachment
      I work for the County Engineer, who maintains the roads in the smaller
      towns and out in the country. I am working on an app for the Sign
      Crew. About 10% of our signs are non-standard in some way, and since
      they are graphic, it would take 1000 words to fully describe them.

      Trying to enforce the sign designers putting "keywords" into a db for
      the crews to search is beyond my ability. We've been supposed to
      supply keywords for our MS Office files for years, and no one does.
      Hey, I don't!

      I want to make the signs "searchable" by using SVG, (I guess,) so that
      the legend is searchable, as is the color of the film, and the
      dimensions of the backing plate and mounting holes, and any standard
      included graphics. That way, if the sign has a right arrow, with a
      railroad track, and no text legend at all, the crew can search for
      "arrow" and "railroad" and get back all the signs that include an
      arrow and a railroad graphic.

      Stuff like that. Is this even possible? Is there a better way?
    • W. Hugh Chatfield I.S.P.
      I suppose the general solution lies with XML (of which SVG is a specific application). The SVG is certainly searchable .. but I wonder if it is sufficient?
      Message 2 of 7 , May 4, 2004
      • 0 Attachment
        I suppose the general solution lies with XML (of which SVG is a specific
        application). The SVG is certainly searchable .. but I wonder if it is
        sufficient? i.e. that set of instructions which when rendered is a
        physical "picture" of the sign may be a necessary but not a "complete set"
        of info required for the sign. You may want to take a look at some of the
        XML "meta languages" (RDF, Topic Maps etc) which would allow you also
        capture info that would reside outside the info required to render a picture
        of the sign.. and then the entire set of info would be searchable.

        Cheers...Hugh

        CyberSpace Industries 2000 Inc.
        XML Training and Consulting
        http://www.urbanmarket.com/csi2000

        Visit Historic Perth Ontario at http://all-about-perth.com


        -----Original Message-----
        From: Ron [mailto:tiltbike@...]
        Sent: Tuesday, May 04, 2004 11:51 AM
        To: metaphorical@yahoogroups.com
        Subject: [metaphorical] SVG?


        I work for the County Engineer, who maintains the roads in the smaller
        towns and out in the country. I am working on an app for the Sign
        Crew. About 10% of our signs are non-standard in some way, and since
        they are graphic, it would take 1000 words to fully describe them.

        Trying to enforce the sign designers putting "keywords" into a db for
        the crews to search is beyond my ability. We've been supposed to
        supply keywords for our MS Office files for years, and no one does.
        Hey, I don't!

        I want to make the signs "searchable" by using SVG, (I guess,) so that
        the legend is searchable, as is the color of the film, and the
        dimensions of the backing plate and mounting holes, and any standard
        included graphics. That way, if the sign has a right arrow, with a
        railroad track, and no text legend at all, the crew can search for
        "arrow" and "railroad" and get back all the signs that include an
        arrow and a railroad graphic.

        Stuff like that. Is this even possible? Is there a better way?





        Yahoo! Groups Links
      • David Dodds
        Hi Ron SVG provides a number of elements in the language which can be used to help you to achieve what you wish. Hugh Chatfield has mentioned that SVG supports
        Message 3 of 7 , May 4, 2004
        • 0 Attachment
          Hi Ron

          SVG provides a number of elements in the language
          which can be used to help you to achieve what you
          wish. Hugh Chatfield has mentioned that SVG supports
          the use of embedded metadata, RDF by default.

          SVG has "id" parameters in each SVG graphic element or
          group name. For example id="track", which could be
          either the id of an SVG group which is basically a
          collection of SVG elements to perform some desired
          activity, or it could be on a single SVG element such
          as "path" which allows you to define a figure, such as
          an arrow. You can use different fills for color, and
          edges too.

          Further there is the SVG "Title" and the "Description"
          element which you could use to give a title/name to an
          element, again such as "track" and "railroad track
          crossing symbol". Since these two elements may have a
          namespace used in them it is possible for you to embed
          metadata in them as well as text. The metadata could
          use a standard or it could be a metadata taxonomy that
          you custom define yourself to your own needs.

          Keep in mind that SVG is XML and you need to parse it
          to search it, so you need to use XML tools.

          There is an XML friendly data base system called
          Xindice, at The Apache Project, which you might also
          look into.

          Perhaps you will look at the metadata examples I made
          in the SVG 1.0 spec at W3C, to get some ideas. Also a
          good reference for ideas is WROX Professional XML Meta
          Data. Many universities would have a copy, as well as
          your bookstore.

          David Dodds

          --- Ron <tiltbike@...> wrote:
          > I work for the County Engineer, who maintains the
          > roads in the smaller
          > towns and out in the country. I am working on an app
          > for the Sign
          > Crew. About 10% of our signs are non-standard in
          > some way, and since
          > they are graphic, it would take 1000 words to fully
          > describe them.
          >
          > Trying to enforce the sign designers putting
          > "keywords" into a db for
          > the crews to search is beyond my ability. We've been
          > supposed to
          > supply keywords for our MS Office files for years,
          > and no one does.
          > Hey, I don't!
          >
          > I want to make the signs "searchable" by using SVG,
          > (I guess,) so that
          > the legend is searchable, as is the color of the
          > film, and the
          > dimensions of the backing plate and mounting holes,
          > and any standard
          > included graphics. That way, if the sign has a right
          > arrow, with a
          > railroad track, and no text legend at all, the crew
          > can search for
          > "arrow" and "railroad" and get back all the signs
          > that include an
          > arrow and a railroad graphic.
          >
          > Stuff like that. Is this even possible? Is there a
          > better way?
          >
          >





          __________________________________
          Do you Yahoo!?
          Win a $20,000 Career Makeover at Yahoo! HotJobs
          http://hotjobs.sweepstakes.yahoo.com/careermakeover
        • Ron
          ... wrote(in part): ... Thanks for unpacking this topic; it may be very useful for this application. I will be looking at the examples
          Message 4 of 7 , May 5, 2004
          • 0 Attachment
            --- In metaphorical@yahoogroups.com, David Dodds
            <david_dodds_2001@y...> wrote(in part):

            Embedded Metadata:
            > SVG provides a number of elements in the language
            > which can be used to help you to achieve what you
            > wish. Hugh Chatfield has mentioned that SVG supports
            > the use of embedded metadata, RDF by default.

            > Further there is the SVG "Title" and the "Description"
            > element which you could use to give a title/name to an
            > element, again such as "track" and "railroad track
            > crossing symbol". Since these two elements may have a
            > namespace used in them it is possible for you to embed
            > metadata in them as well as text. The metadata could
            > use a standard or it could be a metadata taxonomy that
            > you custom define yourself to your own needs.

            > Perhaps you will look at the metadata examples I made
            > in the SVG 1.0 spec at W3C, to get some ideas. Also a
            > good reference for ideas is WROX Professional XML Meta
            > Data. Many universities would have a copy, as well as
            > your bookstore.

            Thanks for unpacking this topic; it may be very useful for this
            application. I will be looking at the examples and perhaps getting a
            copy of the book.

            I am hoping to make a graphic representation of a sign's design that
            has 'inherent' attributes. E.g., if the designer specifies fluorescent
            orange film, the graphic AND its associated SVG will both show up as
            "orange". The SVG will also have an attribute of "h1" (which, I
            believe, is the sign expert's code for fluorescent orange film.)

            The sign cutting machine reads a CorelDraw .cdr file and turns it into
            movement of the cutter. Why on earth the maker of the device chose to
            read a proprietary file format (that the vendor alters with every new
            release) is beyond me, but there it is. I, at any rate, hope to base
            my app on something open source (SVG), which CorelDraw can import and
            export. What they do internally is their business.

            > There is an XML friendly data base system called
            > Xindice, at The Apache Project, which you might also
            > look into.

            Definitely! So, today is "research embedded metadata in the title and
            description fields" day for me. Thanks again, both of you. Just what I
            hoped for from this group.

            Ron
          • Danny Ayers
            Just to add a note to what s been suggested already - and are probably most useful for the kind of task you re describing, though the
            Message 5 of 7 , May 5, 2004
            • 0 Attachment
              Just to add a note to what's been suggested already - <title> and
              <description> are probably most useful for the kind of task you're
              describing, though the RDF in <metadata> approach has the advantage that
              you can say anything about anything, and is potentially as fine-grained
              as you could ever wish for (at the possible cost of extra tools).

              See also - RDF Primer:
              http://www.w3.org/TR/rdf-primer/

              Cheers,
              Danny.

              Ron wrote:

              >--- In metaphorical@yahoogroups.com, David Dodds
              ><david_dodds_2001@y...> wrote(in part):
              >
              >Embedded Metadata:
              >
              >
              >>SVG provides a number of elements in the language
              >>which can be used to help you to achieve what you
              >>wish. Hugh Chatfield has mentioned that SVG supports
              >>the use of embedded metadata, RDF by default.
              >>
              >>
              >
              >
              >
              >>Further there is the SVG "Title" and the "Description"
              >>element which you could use to give a title/name to an
              >>element, again such as "track" and "railroad track
              >>crossing symbol". Since these two elements may have a
              >>namespace used in them it is possible for you to embed
              >>metadata in them as well as text. The metadata could
              >>use a standard or it could be a metadata taxonomy that
              >>you custom define yourself to your own needs.
              >>
              >>
              >
              >
              >
              >>Perhaps you will look at the metadata examples I made
              >>in the SVG 1.0 spec at W3C, to get some ideas. Also a
              >>good reference for ideas is WROX Professional XML Meta
              >>Data. Many universities would have a copy, as well as
              >>your bookstore.
              >>
              >>
              >
              >Thanks for unpacking this topic; it may be very useful for this
              >application. I will be looking at the examples and perhaps getting a
              >copy of the book.
              >
              >I am hoping to make a graphic representation of a sign's design that
              >has 'inherent' attributes. E.g., if the designer specifies fluorescent
              >orange film, the graphic AND its associated SVG will both show up as
              >"orange". The SVG will also have an attribute of "h1" (which, I
              >believe, is the sign expert's code for fluorescent orange film.)
              >
              >The sign cutting machine reads a CorelDraw .cdr file and turns it into
              >movement of the cutter. Why on earth the maker of the device chose to
              >read a proprietary file format (that the vendor alters with every new
              >release) is beyond me, but there it is. I, at any rate, hope to base
              >my app on something open source (SVG), which CorelDraw can import and
              >export. What they do internally is their business.
              >
              >
              >
              >>There is an XML friendly data base system called
              >>Xindice, at The Apache Project, which you might also
              >>look into.
              >>
              >>
              >
              >Definitely! So, today is "research embedded metadata in the title and
              >description fields" day for me. Thanks again, both of you. Just what I
              >hoped for from this group.
              >
              >Ron
              >
              >
              >
              >
              >
              >Yahoo! Groups Links
              >
              >
              >
              >
              >
              >
              >
              >


              --
              ----
              Raw
              http://dannyayers.com
            • Ron
              I received the following out of the group, but it seemed apropos, and so I edited off the signature and post the rest: Hi Ron, It seems to me that the
              Message 6 of 7 , May 6, 2004
              • 0 Attachment
                I received the following out of the group, but it seemed apropos, and
                so I edited off the signature and post the rest:

                <clip>

                Hi Ron,

                It seems to me that the two answers to your posting to
                metaphorical@yahoogroups.com both missed the point. You asked if SVG
                would give you a way of searching a database of signs, with the
                graphics
                expressed in SVG. They said you could add metadata to the SVG XML
                (e.g. RDF) - but you'd already said you were trying to avoid adding
                in
                extra metadata.

                What (I think) you want is for some system to be able to inspect the
                actual graphics, and report on the actual design of the sign. Thus,
                if you use a <circle> element with a radius of 5 mm for fixing holes,
                then presumably you'd like to be able to find all such elements, check
                on their relative x,y coordinates, and infer that it is fixing system
                5 (say, 2 rows of 3 holes each).

                Similarly, the system can infer that there is a right-pointing arrow
                by reasoning with the basic graphical shapes.

                Well, this is indeed possible, without adding any extra metadata: you
                simply use a graphics package with the ability to export SVG, then
                write tools that can reason with the SVG elements in the exported
                documents. You could use XSLT, or any language with an XML DOM
                interface (i.e. any language at all). Some things would be easy;
                others could be pretty difficult (you're getting into
                pattern-recognition territory). But the nice thing is you
                could start off with the easy stuff, and incrementally imrpove your
                system.

                ...

                I'd certainly steer well clear of mandatory metadata until you have
                done as much as you can to infer things from the SVG itself.

                </clip>

                What I am considering, based on the help you've all provided so far:

                a database of "signparts" in SVG, with a drag-and-drop means of
                "assembling" them into signs. The metadata would be inherent in the
                signpart: a "hole" signpart would look like a circle with a name of
                "hole." A "round_backplate" signpart would be a circle with a name of
                "round_backplate". The set of all hole signparts would constitute the
                "fixing" (U.S.:the "mounting.") A "legend" signpart would just be a
                text entity named "legend". A "right_arrow" signpart would be an
                appropriate path named "right_arrow," and so on.

                It would get around most of the threat of needing pattern recognition
                (far beyond my skills) and would minimize the need for my users to
                enter the metadata. I wouldn't see using the resulting files to cut
                the signs, just as a Not Perfectly Accurate way to make a text-
                searchable entity that renders as a reasonable facsimile of the sign.

                Maybe I should do it as a plug-in for Dia (
                http://www.gnome.org/projects/dia/">Dia ). That would
                save me making a lot
                of the UI, and would make it available to others as well.
              • David Dodds
                Perhaps if you bothered to check out the resource I mentioned, WROX Professional XML Meta Data , you would find there chapters which I wrote which explain
                Message 7 of 7 , May 6, 2004
                • 0 Attachment
                  Perhaps if you bothered to check out the resource I
                  mentioned, WROX Professional XML Meta Data , you would
                  find there chapters which I wrote which explain
                  exactly the kind of thing contained in the message
                  below.

                  I have presented conference papers for several years
                  about exactly this sort of thing. If you use Google
                  you can find (my and other's) papers on techniques to
                  do this. Take a look at the SVGOpen 2003 conference.


                  --- Ron <tiltbike@...> wrote:
                  > I received the following out of the group, but it
                  > seemed apropos, and
                  > so I edited off the signature and post the rest:
                  >
                  > <clip>
                  >
                  > Hi Ron,
                  >
                  > It seems to me that the two answers to your posting
                  > to
                  > metaphorical@yahoogroups.com both missed the point.
                  > You asked if SVG
                  > would give you a way of searching a database of
                  > signs, with the
                  > graphics
                  > expressed in SVG. They said you could add metadata
                  > to the SVG XML
                  > (e.g. RDF) - but you'd already said you were trying
                  > to avoid adding
                  > in
                  > extra metadata.
                  >
                  > What (I think) you want is for some system to be
                  > able to inspect the
                  > actual graphics, and report on the actual design of
                  > the sign. Thus,
                  > if you use a <circle> element with a radius of 5 mm
                  > for fixing holes,
                  > then presumably you'd like to be able to find all
                  > such elements, check
                  > on their relative x,y coordinates, and infer that it
                  > is fixing system
                  > 5 (say, 2 rows of 3 holes each).
                  >
                  > Similarly, the system can infer that there is a
                  > right-pointing arrow
                  > by reasoning with the basic graphical shapes.
                  >
                  > Well, this is indeed possible, without adding any
                  > extra metadata: you
                  > simply use a graphics package with the ability to
                  > export SVG, then
                  > write tools that can reason with the SVG elements in
                  > the exported
                  > documents. You could use XSLT, or any language with
                  > an XML DOM
                  > interface (i.e. any language at all). Some things
                  > would be easy;
                  > others could be pretty difficult (you're getting
                  > into
                  > pattern-recognition territory). But the nice thing
                  > is you
                  > could start off with the easy stuff, and
                  > incrementally imrpove your
                  > system.
                  >
                  > ...
                  >
                  > I'd certainly steer well clear of mandatory metadata
                  > until you have
                  > done as much as you can to infer things from the SVG
                  > itself.
                  >
                  > </clip>
                  >
                  > What I am considering, based on the help you've all
                  > provided so far:
                  >
                  > a database of "signparts" in SVG, with a
                  > drag-and-drop means of
                  > "assembling" them into signs. The metadata would be
                  > inherent in the
                  > signpart: a "hole" signpart would look like a circle
                  > with a name of
                  > "hole." A "round_backplate" signpart would be a
                  > circle with a name of
                  > "round_backplate". The set of all hole signparts
                  > would constitute the
                  > "fixing" (U.S.:the "mounting.") A "legend" signpart
                  > would just be a
                  > text entity named "legend". A "right_arrow" signpart
                  > would be an
                  > appropriate path named "right_arrow," and so on.
                  >
                  > It would get around most of the threat of needing
                  > pattern recognition
                  > (far beyond my skills) and would minimize the need
                  > for my users to
                  > enter the metadata. I wouldn't see using the
                  > resulting files to cut
                  > the signs, just as a Not Perfectly Accurate way to
                  > make a text-
                  > searchable entity that renders as a reasonable
                  > facsimile of the sign.
                  >
                  > Maybe I should do it as a plug-in for Dia (
                  > http://www.gnome.org/projects/dia/">Dia ). That
                  > would
                  > save me making a lot
                  > of the UI, and would make it available to others as
                  > well.
                  >
                  >





                  __________________________________
                  Do you Yahoo!?
                  Win a $20,000 Career Makeover at Yahoo! HotJobs
                  http://hotjobs.sweepstakes.yahoo.com/careermakeover
                Your message has been successfully submitted and would be delivered to recipients shortly.