MetaData - type...
Daid
Hod Lipson
We are struggling with how to define the metadata. If we allow custom tags, then files will not be interoperable.
Perhaps its best if we keep th e”must be one of the following” but then add new terms as needed.
We replaced “cad” with “producer” because often the file is generated by things other than CAD, e.g. by scanning software.
Lets us know what categories are missing, and if we should also reinstate “cad”
--hod
Hod Lipson
Associate Prof. of Mechanical & Aerospace Engineering and Computing & Information Science
Cornell University, 242 Upson Hall, Ithaca NY 14853, USA
Office: (607) 255 1686 Lab: (607) 254 8940 Fax: (607) 255 1222
Email: Hod.L...@cornell.edu
Web: http://www.mae.cornell.edu/lipson
Administrative Assistant: Craig Ryan cd...@cornell.edu
--
You received this message because you are subscribed to the Google Groups "STL 2.0" group.
To unsubscribe from this group and stop receiving emails from it, send an email to
stl2+uns...@googlegroups.com.
To post to this group, send email to st...@googlegroups.com.
Visit this group at http://groups.google.com/group/stl2?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.
Martin Wicke
of the standard. Hod, would you mind sending me the up-to-date version
under discussion?
I feel pretty strongly that the metadata field should not be restricted.
If you want to encode very specific things (and make sure only those are
found in the designated place), then they can have their own tag. For
instance, producer could look like this:
<amf>
<producer>mememe</producer
...
</amf>
Instead of
<amf>
<metadata type="producer">mememe<metadata>
...
</amf>
If I can only use a discrete set of metadata types, then they could just
all be tags and there would be no ambiguity. In my opinion, the metadata
tag only makes sense if the type is open to whatever you want to put in
there. It will be impossible to anticipate quickly enough all the
possible pieces of data that users will want to store in metadata
(physical parameters alone are too many to enumerate, and honestly, we
probably lack the knowledge to do that in a sensible manner).
Arguably, you could of course just add your own tag for things that are
not part of the allowed metadata types. But that does nothing to further
interoperability. On the contrary. Now I have unknown tags with unknown
content, instead of metadata tags with unknown type and string content.
Always the pessimist, I predict that these things will happen if you
restrict the metadata types:
- People will ignore the restrictions
- People will abuse 'legal' metadata types for unrelated data ("I want
to store the depth resolution of the scanner in the AMF, but there isn't
an appropriate field, but look, 'tolerance'... it's close enough!"
- People will abuse a metadata types to just dump data into ("I want to
store 15 other material parameters, I'll just dump a base64 encoded
string into the description metadata")
- People will adhere to the standard, and simply add another tag
<mymetadata> which will have unknown structure and only their
proprietary reader will be able to interpret.
All these things are not pretty, but ignoring the restrictions is
arguably the least harmful. I believe that a semi-structured container
(list of strings with arbitrary semantics, like metadata) is essential
for a complex format like AMF, and taking away easy (and by easy, I mean
very easy) extensibility, without going through the standard process,
would be a bad mistake.
Martin
Hod Lipson wrote:
> We are struggling with how to define the metadata. If we allow custom
> tags, then files will not be interoperable.
>
>
>
> Lets us know what categories are missing, and if we should also
>
> --hod
>
> _Hod Lipson_
> Associate Prof. of Mechanical & Aerospace Engineering and Computing &
> Information Science
>
> Cornell University, 242 Upson Hall, Ithaca NY 14853, USA
>
> Office: (607) 255 1686 Lab: (607) 254 8940 Fax: (607) 255 1222
>
>
> Web: http://www.mae.cornell.edu/lipson
>
> *Administrative Assistant:*Craig Ryan cd...@cornell.edu
> <mailto:cd...@cornell.edu>
>
> *Calendar*: http://www.mae.cornell.edu/lipson/calendar.htm
>
> *From:*st...@googlegroups.com [mailto:st...@googlegroups.com] *On Behalf
> Of *Daid
> *Sent:* Monday, April 08, 2013 11:43 AM
> *To:* st...@googlegroups.com
> *Subject:* MetaData - type...
> The AMF standard states about the "type" attribute in the <MetaData>
> tag, the following:
>
> "elasticmodulus", "poissonratio" or "colorprofile".
>
> (emphasis mine)
>
> So there is no room for custom/vendor specific meta data? Also, the
> examples show an impossible value, both on wikipedia and the standard
> itself show type="cad" as option.
>
> The standard in section 11 says "Annex A1 lists reserved metadata types
> and their meaning." so maybe the "must" in the Annex is wrong and should
> say, "The following values are reserved for..."
>
> --
> You received this message because you are subscribed to the Google
> Groups "STL 2.0" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to stl2+uns...@googlegroups.com
Hod Lipson
True, we can't predict everything, but we can predict that some things will be important as metadata, and at least try to have those covered.
Not sure what other solution we have...
--hod
>
>
> Lets us know what categories are missing, and if we should also
Martin Wicke
like what you have. The only change I would make is to not disallow
other types.
Type custom is a compromise, but it makes metadata a little less useful
by taking away type/value pairs and replacing them with just a list of
string values. So now I effectively have to store the type inside the
data myself (for instance, by storing "permeability=.5"). I am not sure
what would be gained by that over just letting people use their own types.
Jacob Barhak
Jesse McGatha
Daid
Hod Lipson
while we sort this out, I think that for this revision we should leave the <metadata> as is, with requirement that the type “must” be one of the reserved words.
Then we can discuss more options and we should talk about namespaces in general.
--hod
Hod Lipson
Associate Prof. of Mechanical & Aerospace Engineering and Computing & Information Science
Cornell University, 242 Upson Hall, Ithaca NY 14853, USA
Office: (607) 255 1686 Lab: (607) 254 8940 Fax: (607) 255 1222
Email: Hod.L...@cornell.edu
Administrative Assistant: Craig Ryan cd...@cornell.edu
Calendar: http://www.mae.cornell.edu/lipson/calendar.htm
Rene K. Mueller
On Monday, April 8, 2013 6:47:35 PM UTC+2, Hod Lipson wrote:
We are struggling with how to define the metadata. If we allow custom tags, then files will not be interoperable.
Perhaps its best if we keep th e”must be one of the following” but then add new terms as needed.
Rene K. Mueller
On Monday, April 8, 2013 11:54:09 PM UTC+2, Daid wrote:
Perhaps make it "one of the following, or starting with 'custom:[software_package_name]:[typename]'I see the possibility to use AMF as "main" storage format for Cura, but for that I need a place to store some extra data, for example, per object slicer settings (which won't cross over to other software very well, but can still be ignored fine without losing important model data)
Jacob Barhak
--
Hod Lipson
We tried to have the AMF only describe properties of the final object, not properties of the steps to make it.
So we avoid printer-specific information such as a list of slices and tool paths.
All 3D printers today read a temporary intermediate file that is generated from the STL/AMF. So there could be some cloud service that would generate those files on the fly for a specific printer, if necessary.
--hod
Jesse McGatha
Jesse McGatha
On Tuesday, April 9, 2013 12:07:19 PM UTC-7, Rene K. Mueller wrote:
Metadata should kept flexible, with a few clear definition, e.g. "name", "description", "url", "author", "company", "producer", "revision", those and a few others I can throw in should be described in details (e.g. "tolerance", "volume", "elasticmodulus", "poissonratio" or "colorprofile") what they mean (with plenty examples of the non obvious ones); but there should *no* "must be one of the following" - this runs against the openness, runs against the entire idea of metadata: I do want to store there relevant data from OpenJSCAD, e.g. history, how this AMF came from (e.g. *date* of original .jscad file, *date* of creation of the AMF itself, version of the original .jscad file, license, and on and on; and when I think of carrying over metadata from ThingTracker, see http://thingtracker.net, yes, I like to have the option to put this into the AMF as well and extracted on-demand, also when .jscad is detached. Why lock down metadata?
Rene K. Mueller
On Tuesday, April 9, 2013 10:39:28 PM UTC+2, Jacob Barhak wrote:
Hi All,Rene mentioned slice info. Does AMF support describing an object by its slices rather than by geometry? I did not see this in Wikipedia.Is this something you are considering in future versions?
Martin Wicke
--
Rene K. Mueller
On Tuesday, April 9, 2013 11:23:15 PM UTC+2, Jesse McGatha wrote:
On Tuesday, April 9, 2013 12:07:19 PM UTC-7, Rene K. Mueller wrote:Metadata should kept flexible, with a few clear definition, e.g. "name", "description", "url", "author", "company", "producer", "revision", those and a few others I can throw in should be described in details (e.g. "tolerance", "volume", "elasticmodulus", "poissonratio" or "colorprofile") what they mean (with plenty examples of the non obvious ones); but there should *no* "must be one of the following" - this runs against the openness, runs against the entire idea of metadata: I do want to store there relevant data from OpenJSCAD, e.g. history, how this AMF came from (e.g. *date* of original .jscad file, *date* of creation of the AMF itself, version of the original .jscad file, license, and on and on; and when I think of carrying over metadata from ThingTracker, see http://thingtracker.net, yes, I like to have the option to put this into the AMF as well and extracted on-demand, also when .jscad is detached. Why lock down metadata?Metadata must be locked down to prevent 2 scenarios:1) Some popular software starts emitting metadata with a name that is later included in the spec with requirements for its value. A strictly-compliant consumer would have to reject potentially tens of thousands of documents generated prior to the introduction of the custom keyword from this one producer.
2) Two different pieces of software try to read/write the same custom metadata field with the same name. These were developed independently, but the names now collide, with different semantics of the values. Who wins? This is very messy and should be avoided through proper scoping of the name to an individual producer or target consumer. The best way to do this is an XML namespace-prefixed QName for the name value.
Hod Lipson
I think the idea of “xtype=mytype” is great – it solves problem 1.
Add an “xowner=myorgname” (where myorgname is the url of the owner of the extended type, e.g. “microsoft.com”) and we can solve both issues 1 and 2.
As for namespaces, do we need to do anything specific for an amf namespace?
We can just add at the root xmlns:amf=“www.astm.org/Standards/F2915.htm”
I will add this to the current revision.
--hod
From: st...@googlegroups.com [mailto:st...@googlegroups.com]
On Behalf Of Rene K. Mueller
Sent: Tuesday, April 09, 2013 5:37 PM
To: st...@googlegroups.com
Subject: Re: MetaData - type...
--
Jesse McGatha
Hod Lipson
If the slices are not to serve as direct toolpath instructions, but are an abstract way to describe the geometry, then they would be appropriate for the AMF.
However, in that case they would have to go under something different than <mesh>
Right now we only have <mesh>. But we could also have “<slices>”, “<voxels>” and “<frep>” which are all different ways to describe geometry.
They would need their own definitions.
In my opinion we should wait for good AMF adoption with mesh (the most similar to STL) before we introduce other formats.
However, if people want it we can do it.
Would anyone be interested in leading a <slices> element, i.e. proposing definitions, writing open-source reference code, and providing sample objects?
(Same question for <voxel> and <frep>)
--hod
From: st...@googlegroups.com [mailto:st...@googlegroups.com] On Behalf Of Jesse McGatha
Sent: Tuesday, April 09, 2013 5:18 PM
To: st...@googlegroups.com
Jacob Barhak
Sent from my iPhone
Jacob Barhak
Sent from my iPhone
Hod Lipson
I am in favor of AMF supporting alternative geometric representations: voxels, slices, and function-representations.
However, what you are describing below sounds like printer-specific slice-by slice process parameters and that is not in the scope of AMF because it may not work on a different printer with different slice thickness.
Can you be more specific about what properties you would like to specify? Maybe we can find a way to embed those as abstract volume properties, so they can be used by any printer regardless of slices thickness.
--hod
From: Alejandro Sklar [mailto:alejand...@gmail.com]
Sent: Wednesday, April 10, 2013 3:34 AM
To: st...@googlegroups.com
Subject: Re: Does AMF support slice data?
I think exploring with new elements, especially different geometrical representations, has a lot of potential. In the case of slices, their structure basically mimics the sequential print path. Thus embedding information about the printing process within this type of representation would be simpler than embedding information within a mesh representation.
This could be useful when developing custom code for controlling other parameters and functions of the printing process. For instance, if someone wants to be able to choose different print settings for different portions of the printed piece, they could merely add custom tags around the single block of sequential code that defines the geometry of that region. It seems to me that attempting to do this with a surface mesh representation would require some messy transformations, or the excessive repetition of parameters.
I too feel it's important to address a procedure for possible additions to the standard because I personally feel there might be more properties of the final object that should be explored, beyond geometry and material. These could provide developers that use AMF simple ways of embedding other printing information to make full use of the additive manufacturing process.
- Alejandro
--
CTO & Co-founder
Hod Lipson
I think we should first reaffirm or refute the principle that AMF should only state properties of the final object (like STL), and not printer-specific process parameters.
If we abandon this principle we make the any AMF file less universal, and we should not do that incrementally.
In my personal opinion, adding printer-specific process parameters would be a mistake. I understand the convenience of adding process parameters in a closed research environment, and you can certainly do that in house, but making that part of the official standard has long term ramifications. For example, it is possible to describe geometry by slices with slice-by-slice nozzle temperatures etc. But that file would be un-interpretable by a printer with a different thickness or a printer that does not use a nozzle. Similarly, adding <future> and <custom> and <depreciated> are all cracks in the foundations that go against the very idea of a standard.
XML namespaces already allow you to insert elements from a different namespace. So why not create a new namespace (e.g. “AMF-Future:”) and you can add whatever you want without interfering with the official standard?
I would like to hear more people share their opinion on either side.
--hod
Hod Lipson
Associate Prof. of Mechanical & Aerospace Engineering and Computing & Information Science
Cornell University, 242 Upson Hall, Ithaca NY 14853, USA
Office: (607) 255 1686 Lab: (607) 254 8940 Fax: (607) 255 1222
Email: Hod.L...@cornell.edu
Web: http://www.mae.cornell.edu/lipson
Administrative Assistant: Craig Ryan cd...@cornell.edu
Jonathan Hiller
TAGS must:
How do you know?
*Can the contents of the tag mess up another piece of hardware if followed? If yes, then probably not appropriate. For instance if a <BuildTemperature> is specified, another machine could fry itself trying to reach that temperature.
GEOMETRY representations must:
Jacob's point about a probably use-case of small cloud-connected 3d printers is well taken. However this is the interface between AMF and a specific printer or class of printers. I think an efficient, standard slice streaming format closely tied to AMF would be the correct solution for this scenario. This could be included in the same AMF spec document without burdening the actual AMF files with additional hardware-specific information.
I think we should first reaffirm or refute the principle that AMF should only state properties of the final object (like STL), and not printer-specific process parameters.
If we abandon this principle we make the any AMF file less universal, and we should not do that incrementally.
In my personal opinion, adding printer-specific process parameters would be a mistake. I understand the convenience of adding process parameters in a closed research environment, and you can certainly do that in house, but making that part of the official standard has long term ramifications. For example, it is possible to describe geometry by slices with slice-by-slice nozzle temperatures etc. But that file would be un-interpretable by a printer with a different thickness or a printer that does not use a nozzle. Similarly, adding <future> and <custom> and <depreciated> are all cracks in the foundations that go against the very idea of a standard.
XML namespaces already allow you to insert elements from a different namespace. So why not create a new namespace (e.g. “AMF-Future:”) and you can add whatever you want without interfering with the official standard?
I would like to hear more people share their opinion on either side.
--hod
Hod Lipson
Associate Prof. of Mechanical & Aerospace Engineering and Computing & Information Science
Cornell University, 242 Upson Hall, Ithaca NY 14853, USA
Office: (607) 255 1686 Lab: (607) 254 8940 Fax: (607) 255 1222
Email: Hod.L...@cornell.edu
Web: http://www.mae.cornell.edu/lipson
Administrative Assistant: Craig Ryan cd...@cornell.edu
From: st...@googlegroups.com [mailto:st...@googlegroups.com] On Behalf Of Jacob Barhak
Sent: Wednesday, April 10, 2013 2:49 AM
Markus Hitter
Am 10.04.2013 um 16:26 schrieb Hod Lipson:
> In my personal opinion, adding printer-specific process parameters
> would be a mistake. I understand the convenience of adding process
> parameters in a closed research environment, and you can certainly
> do that in house, but making that part of the official standard has
> long term ramifications. For example, it is possible to describe
> geometry by slices with slice-by-slice nozzle temperatures etc. But
> that file would be un-interpretable by a printer with a different
> thickness or a printer that does not use a nozzle. Similarly,
> adding <future> and <custom> and <depreciated> are all cracks in
> the foundations that go against the very idea of a standard.
I even expect slice files to become obsolete in a not too distant
future, because printers will handle that internally. Just like most
2D printers no longer handle pixel-by-pixel image descriptions,
because they have technologies which can't be described pixel-by-
pixel and give better printing results.
Markus
- - - - - - - - - - - - - - - - - - -
Dipl. Ing. (FH) Markus Hitter
http://www.jump-ing.de/
Hod Lipson
Does anyone involved with ASTM know what happened to that effort?
--hod
-----Original Message-----
From: st...@googlegroups.com [mailto:st...@googlegroups.com] On Behalf Of Markus Hitter
Sent: Wednesday, April 10, 2013 1:02 PM
To: st...@googlegroups.com
Subject: Re: Does AMF support slice data?
Jacob Barhak
This issue is similar to how this the client should be in a client/server application.
Who is responsible for what kind processing has been changing for years back and forth since terminals and central computers have been created.
Today for example the shift is towards heavy computations in the cloud and GUI via a web browser at the client. If the 3D printing field agrees on a printer standard such as HTML for browsers then you are right - and that standard may be AMF. Yet if streaming control information will be a better alternative then perhaps the market will shift.
Note, however, that since STL was there first, chances are that AMF has more chances of adoption than the scenario I was describing with slices/control information.
I am just trying to keep an open mind.
Jacob
Sent from my iPhone
>
> Am 10.04.2013 um 16:26 schrieb Hod Lipson:
>
>> In my personal opinion, adding printer-specific process parameters would be a mistake. I understand the convenience of adding process parameters in a closed research environment, and you can certainly do that in house, but making that part of the official standard has long term ramifications. For example, it is possible to describe geometry by slices with slice-by-slice nozzle temperatures etc. But that file would be un-interpretable by a printer with a different thickness or a printer that does not use a nozzle. Similarly, adding <future> and <custom> and <depreciated> are all cracks in the foundations that go against the very idea of a standard.
>> ...
>> I would like to hear more people share their opinion on either side.
>
> You're absolutely right, that's why I didn't speak up so far.
>
>
> Markus
>
> - - - - - - - - - - - - - - - - - - -
> Dipl. Ing. (FH) Markus Hitter
> http://www.jump-ing.de/
>
>
>
>
>
Martin Wicke
makes a lot of sense to me since geometry is a universal interchange
format. Slicing on the other hand is just one method of manufacturing,
relevant only for (most) 3D printers, and some 3-axis mills. Slices are
far from universal.
I agree that AMF should not include (and therefore tempt producers to
produce) machine or process specific data *in the geometry
specification*. I do not think that should mean that all
process-specific data should be forbidden: I think it is fair to enter
parameters relating to the scanning process for scanned geometry (the
right place IMO is <metadata>), or even suggested parameters for
production (again, in <metadata>). I believe the problems surrounding
these things can be solved with proper namespacing, as discussed
elsewhere. Even better, if such tags/data turn out to be important and
widely adopted, they can be absorbed into the standard (similar to the
ARB/EXT method OpenGL uses).
As Hod said earlier, adding tags other than <mesh> is perfectly
reasonable as long as the contained information describes the geometry
in a "portable" way, for example <frep>, <levelset>, <csg>,
<pointcloud>, etc., but as Jonathan said, it is crucial that exact
instructions are given how to obtain pure geometry from the data
(interpolation schemes for levelsets, implicit surface definition
specifications for point clouds, etc.). Just slices as they are usually
produced by printer drivers now are not enough (since they implicitly
rely on a process to complete the geometry), but slices plus a
definition of how they connect would define a unique geometry, and could
be a way to define a good <slices> tag.
Martin
Markus Hitter wrote:
>
> Am 10.04.2013 um 16:26 schrieb Hod Lipson:
>
>> In my personal opinion, adding printer-specific process parameters
>> would be a mistake. I understand the convenience of adding process
>> parameters in a closed research environment, and you can certainly do
>> that in house, but making that part of the official standard has long
>> term ramifications. For example, it is possible to describe geometry
>> by slices with slice-by-slice nozzle temperatures etc. But that file
>> would be un-interpretable by a printer with a different thickness or a
>> printer that does not use a nozzle. Similarly, adding <future> and
>> <custom> and <depreciated> are all cracks in the foundations that go
>> against the very idea of a standard.
>> ...
>> I would like to hear more people share their opinion on either side.
>
> You're absolutely right, that's why I didn't speak up so far.
>
> I even expect slice files to become obsolete in a not too distant
> future, because printers will handle that internally. Just like most 2D
> printers no longer handle pixel-by-pixel image descriptions, because
Jacob Barhak
Sent from my iPhone
Hod Lipson
How about doing this under a different namespace, like “AMF-Future:” or “AMFX:”.
Then it is completely independent of the AMF standard, and AMF readers can ignore it if they want.
It sounds to me the perfect solution.
Alejandro Sklar
Alejandro Sklar
Jacob Barhak
Sent from my iPhone
Daid
To post to this group, send email to s...@googlegroups.com.
Visit this group at http://groups.google.com/group/stl2?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.
--
You received this message because you are subscribed to the Google Groups "STL 2.0" group.
To unsubscribe from this group and stop receiving emails from it, send an email to stl2+uns...@googlegroups.com.
To post to this group, send email to s...@googlegroups.com.
Visit this group at http://groups.google.com/group/stl2?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.
--
You received this message because you are subscribed to the Google Groups "STL 2.0" group.
To unsubscribe from this group and stop receiving emails from it, send an email to stl2+uns...@googlegroups.com.
To post to this group, send email to s...@googlegroups.com.
Visit this group at http://groups.google.com/group/stl2?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.
--
You received this message because you are subscribed to the Google Groups "STL 2.0" group.
To unsubscribe from this group and stop receiving emails from it, send an email to stl2+uns...@googlegroups.com.
To post to this group, send email to s...@googlegroups.com.
Visit this group at http://groups.google.com/group/stl2?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.